Think enterprise first. Such a simple statement, but yet it is so difficult to do. Admittedly, I am an enterprise architect, so it’s my job to think about the enterprise. In reality, it’s not just my job. If you are an employee, it’s your job, too.
Why am I bringing this up? I believe that having a simple, clear statement that embodies the change that we’re looking for is critical for making that change occur. so, when I sat back and thought about my experiences over the years and tried to think of a general, common problem that needs to change, what became clear was the very project-centric culture of most IT organizations.
Projects are necessary to ensure that delivery occurs, but let’s face it, have you ever been on a project where scope was the least flexible thing? From day one, schedule and resources are always less flexible than scope. As a result, we have an IT culture that is obsessed with on-time, on-budget delivery, that will always sacrifice scope.
While schedule and resources will always wind up being the least flexible thing by the end of the project, it shouldn’t begin that way. The change that must occur is to start out thinking “enterprise first.” The simplest example I can think of this is in service development. What’s the behavior in your organization? Do teams build “their” application and only create services where a clear opportunity for reuse exists (or when a governance team forces them to), or do your teams define their projects as services first (regardless of any known opportunities for reuse) and then add in whatever application-specific stuff is necessary. The latter is an enterprise-first thinking, the former is an example of project-first thinking.
The argument you may have is, “isn’t this going to result in bloated , over-engineered solutions?” It shouldn’t. Making something a service doesn’t require surveying the enterprise for requirements. it means we place the proper ownership and management around that service so that it is positioned for change. We can only design to the knowledge that we have based on past experience and known requirements. We can’t predict what changes will come, we can only make sure we are properly prepared for that change. project-first thinking doesn’t do that, enterprise-first thinking does. Think enterprise first.
While I have not yet embarked on writing another book, I have been published in a second book. The publisher of my book on SOA Governance, Packt Publishing, has released their first compendium title called, “Do more with SOA Integration: Best of Packt.” It features content from several of their SOA books and authors, including some from my book on SOA Governance. If you’re looking for a book that covers a more broader perspective on SOA, but has some great content on SOA Governance as a bonus, check it out.
On a related note, I’ve been toying with the idea of authoring another book, this time on Enterprise Architecture. There are certainly EA books on the market, so I’m interested in whether all of you think there are some gaps in the books available. If I did embark on this project, my goal would be similar to my goal on my SOA Governance book: keep it easily consumable, yet practical, pragmatic, and valuable. That’s part of the reason that I chose the management fable style for SOA Governance, as a story is easier to read than a reference manual. If I can find a suitable story around EA, I may choose the same approach. Please send me your thoughts either by commenting on this post, or via email or LinkedIn message. Thanks for your input.
I saw a tweet today, and while I don’t remember it exactly, it went something like this: “You must be successful with SOA to be successful with the cloud.” My first thought was to write up a blog about the differences between infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS) and how they each relate to SOA until I realized that I wrote exactly that article a while ago as part of my “Ask the Expert” column on SearchSOA.com. I encourage you to read that article, but I quickly thought of another angle on this that I wanted to present here.
What’s the first vendor that comes to mind when you hear the words “cloud computing”? I’m sure someone’s done a survey, but since I don’t work for a research and analysis firm, I can only give you my opinion. For me, it’s Amazon. For the most part, Amazon is an infrastructure as a service provider. So does your success in using Amazon for IaaS have anything to do with your success with SOA? Probably not, however, Amazon’s success at being an IaaS provider has everything to do with SOA.
I’ve blogged previously about the relationship between ITIL/ITSM and SOA, but they still come from very different backgrounds, ITIL/ITSM being from an IT Operations point of view, and SOA being from an application development point of view. Ask an ITIL practitioner about services and you’re likely to hear “service desk” and “tickets” but not so likely to hear “API” or “interface” (although the DevOps movement is certainly changing this). Ask a developer about services and you’re likely to hear “API,” “interface,” or “REST” and probably very unlikely to hear “service desk” or “tickets”. So, why then does Amazon’s IaaS offering, something that clearly aligns better with IT operations, have everything to do with SOA?
To use Amazon’s services, you don’t call the service desk and get a ticket filed. Instead, you invoke a service via an API. That’s SOA thinking. This was brought to light in the infamous rant by Steve Yegge. While there’s a lot in that rant, one nugget of information he shared about his time at Amazon was that Jeff Bezos issued a mandate declaring that all teams will henceforth expose their data and functionality through service interfaces. Sometimes it takes a mandate to make this type of thinking happen, but it’s hard to argue with the results. While some people will still say there’s a long way to go in supporting “enterprise” customers, how can anyone not call what they’ve done a success?
So, getting back to your organization and your success, if there’s one message I would hope you take away from this, it is to remove the barriers. There are reasons that service desks and ticketing systems exist, but the number one factor has to be about serving your customers. If those systems make it inefficient for your customers, they need to get fixed. In my book on SOA Governance, I stated that the best way to be successful is to make the desired path the path of least resistance. There is very little resistance to using the Amazon APIs. Can the same be said of your own services? Sometime we create barriers by the actions we fail to take. By not exposing functionality as a service because your application could just do it all internally, in-process, we create a barrier. Then, when someone else needs it, the path of least resistance winds up being to replicate data, write their own implementation, or anything other than what we’d really like to see. Do you need to be successful with SOA to be successful with the cloud? Not necessarily, but if your organization embraces services-thinking, I think you’ll be positioning for greater success than without it.
On the Forrester Enterprise Architecture Community site, Randy Heffner asked the question, “What should EA do for business agility?” In my two responses in the discussion, I emphasized that EA is all about decision support. Yes, you may create a future state roadmap, but what the organization winds up with is completely dependent on what projects the organization decides to execute, and then on how those efforts are executed. EA influences those decisions, but we’re not the ones making them.
So why is this post titled, “Deciding ‘Yes’ on EA”? In that same discussion, William El Kaim added the following:
Let me be real provocative, and state: EA is dead … It has been killed by architect themselves leaving in their ivory tower and their beautiful EA drawing tool that nobody uses and that contains outdated data when they are published.
You can read the rest of what William had to say on the Forrester site, but I don’t think it’s anything any of us practicing EA’s haven’t heard before. But there’s a very important point in William’s statement. If nobody uses what EA produces but EA themselves, that’s a big problem. Put simply, if we provide poor decision support, the organization will ultimately decide against EA.
Like most things in this world, there are far more ways to fail than there are to succeed. So what are some best practices for providing excellent decision support so that the organization will decide “yes” on EA?
- Figure out who makes the decisions. Sounds simple, right? Not quite. I’d love to see a Forrester or Gartner survey on this one, but I’m willing to clarity and consistency on the decision making process is not a strength for most organizations. Regardless of the state of your decision making process, if you don’t have access to the people making the decisions, you have little to no chance of influencing them.
- Figure out how they make their decisions. Note that I didn’t add, “and make them better.” Remember that they’re the one making the decisions, not you. Your role is to give them added information so that they can make the best decisions possible. In some cases, the whole reason for having the discussion may be so you can learn and incorporate that decision maker’s information into your guidance for other decision makers.
- Make your information relevant to them. Don’t give them a bunch of models that are only meaningful to another EA. In the case of upward decisions, this usually means that the architecture implications have to have financial ties, or clearly alignment with business objectives. I’ve had success using capabilities in these discussions, and I think the current research would back that up. You must tailor your information to their needs. If they don’t understand it, it’s your problem, not theirs. They’re making the decision, not you.
- Emphasize added insight, not oversight. This is very important for interactions with project teams. All too often, EA is positioned as the enforcer. Come before the review board and we shall assess your worthiness. I’m sorry, but a guy who spends 80% of his time writing code each day should be far more aware of the latest frameworks than the average EA. The role of the EA is bring enterprise and/or domain perspective to the effort. As soon as the project gets established, the project blinders go up, and it’s the job of EA to remove those blinders and add enterprise insight into the effort.
- Don’t rely solely on artifacts, and where you must, make sure they are easily digestible. While many factors in an organization lead us toward email-based interactions of documents, try to have a face-to-face conversation about the guidance whenever possible. At a minimum, by walking someone through it, you at least knowing they’re actually reading some part of it. When you create the artifacts, get them to the point.
- Be cautious about consulting models for EA.A consulting model for EA is great, right? When someone needs more information to make a decision, what do they do? They hire a consultant. So EA should be internal consultants, right? Well, not really. That may work in the short term, but it is a “I’m here when you need me” model, when you really want to always be a part of the process. Don’t turn down the consulting approach, as it can get your foot in the door, but make sure you turn it to something more systemic.
What other best practices (or worst practices) do you recommend in firmly establishing EA as a valuable resource in the decision making processes in the organization?
Every organization has one. For some, it can lead directly to a path of enlightenment. Others may use its rigid structure to create an impenetrable fortress of strength. For the unfortunate, it becomes an inescapable labyrinth of hopelessness. Yes, it’s the org chart.
Okay, let’s be fair, it’s actually not the chart that’s the real challenge, it’s the organizational structure. Any organizational structure creates boundaries, and those boundaries create opportunity for divergence, whether in strategy, opinions, processes, or just about anything else. The challenge is figuring out how to structure the organization to diverge where you need divergence, but to be consistent where you want consistency. It’s no surprise that organizational structure is considered by some to be part of the enterprise architecture. Just as we try to organize our technology portfolio in the best manner to achieve the desired business goals, we need to organize our human resources as well. More importantly, just as management may choose to reorganize its human resources as the business goals and operating context changes, the way we organize our technology portfolio needs to change as well.
The organizational structure poses a particular challenge for the practice of architecture, particularly when it comes to solution architecture. I’ve seen at least three different models for organizing the architecture practice. First, is the centralized model where all architects report up to a single Chief Architect or Director of Architecture. There may be some middle management in there, but there is always a solid line leading to the top. As you might guess, this usually leads to a high degree of consistency, but can have challenges in scaling to meet demand, retaining business domain knowledge, and of course, ensuring that the centralized resources actually get used by projects and avoiding “rogue architecture.” The overuse of the term “architect” in job titles these days makes this even more problematic, as senior or lead developers may now have the title of Java/.NET Architect. It may also create delays in decision making, because the solution delivery has one reporting structure, while the solution architecture has a different reporting structure. If there is a disagreement, these two management structures must come together to resolve the difference, or it must be escalated up the chain.
A second model is a separation of the Enterprise Architecture function from the Solution Architecture function. Enterprise Architects have a solid line to the Chief Architect/Director of Architecture, Solution Architects report through a different structure, perhaps having a dotted line back into the EA organization in a matrixed structure. Consistency becomes more of a challenge, because Solution Architects will likely receive more direction from their management structure than from the EA team. It also creates challenges for the EA function, because now the EA team is at risk of being completely disconnected from solution delivery. Even in the centralized model, the bulk of the input into the solution comes from the solution management side of things. Now, that push will be even stronger, with architectural management struggling to maintain a voice. That voice is sometimes mandated through an architectural review board, but if that’s the only time that architectural management has the solution architect’s ear, the effort is likely to struggle with EA being seen as an ivory tower, rather than a necessary contributor to solution success. I’ve seen this model more than either of the others, however.
The third model would be the completely decentralized model. In this case, there is still a practice of architecture in the organization, but it is completely distributed. Solution architects, and perhaps domain architects, are scattered throughout the organization. A virtual team may exist, and there may even be a Chief Architect/Director of Architecture, but the role may largely be one of information sharing and coordination, and not really about architecture management. What’s good is that there’s not much risk of being perceived as an ivory tower, but there is significant risk of poor architectural alignment. If the boundaries of diversification are based upon an assumption that business units do not share customers, what happens if the situation changes and they do? Even ignoring the potential for this situation, decisions on centralization versus a matrixed approach are likely made locally within each business unit.
So what model is right? First, a completely decentralized approach is really only suitable for companies with a completely diversified operating model (see this book if you don’t know what that means). So, it really comes down to centralized versus matrixed, and that will either be applied at the business unit level for a diversified company, or at the enterprise level for other operating models. Both centralized and matrixed can work, but there is a catch. I’ve used the term “architecture management” in this blog. As I wrote this, I kept thinking about parallels to project management and a PMO. I’ve seen centralized PMOs where all project managers report into a single organizational group, and I’ve seen decentralized PMOs where individual project managers report into lines of business while a core group of resources that look at things from a portfolio perspective report into a Director of Product Management. The catch is consistency. If each project manager did things their own way, it is going to be extremely difficult for anyone to manage things at a portfolio level. Without establishing some minimum level of consistency that produces the necessary metrics and information at the right times for portfolio level management to happen, you’re sunk. Fortunately, for project management, the need for this is a well accepted practice. No one wants to wait to find out that a project is $100M over budget until after it happens. If you have that consistency, you can make either model work.
In the case of architecture management, things are still maturing. The problem is that we are at risk of focusing solely on consistency, without properly understanding the outcome that consistency is supposed to create. While finding out that you’re $100M over budget after it’s been spent is well understood as a bad thing, is finding out that someone has built a component that already existed elsewhere in the company a bad thing? Not necessarily. Those decisions need to be made in the context of both the project’s goals and the enterprise’s goals to make that distinction. Pursuing enterprise consistency when there are only project goals involved in decision making puts you at risk of being perceived as an ivory tower. At the same time, it may be necessary to pursue some base level of consistency prior to establishing that enterprise context, otherwise the context may be perceived as irrelevant. This can happen when the practice of solution architecture really isn’t being practiced at all.
My final advice is this: a centralized path will definitely lead to the most consistency, but you have to be rock solid in your justification of the need for an enterprise viewpoint, because that centralized model creates management overhead, risk of resource availability, and the potential for conflicting direction. A decentralized model is at less risk of having resource availability issues, but makes consistency more difficult and is more prone to sacrificing enterprise direction for project delivery. Ultimately, it will come down to whether your organization has been successful with matrix management approaches or not. If it has, you should be able to make a decentralized approach work. If you’ve never been successful with matrix management, then a centralized approach will likely be necessary. Finally, if you go with a decentralized approach, but have very inconsistent architecture practices, I strongly recommend that you establish an architecture mentoring/facilitator practice. In this, members of the centralized EA team facilitate one or two day architectural workshops. This can ensure that things are done in a consistent manner, the voice of the enterprise is brought into the solution architecture process, but the risks associated with a completely centralized model are mitigated.
Amazon released their HTML5 Kindle reader this week, and I couldn’t keep myself from commenting on all of the talk of people saying/hoping/proclaiming that this was the beginning of the end for apps and Apple’s AppStore.
I think it’s great that Amazon has released the HTML5 version of the Kindle reader, complete with integration into the Amazon Kindle store. I don’t see Amazon pulling their Kindle app from the app store though, and I think there would probably be a big revolt if they did.
It seems that a lot of the pundits out there think that all of the developers out there are just waiting to jump on a single technology that will support any device, anywhere. For developers that aren’t making any money on their products, that may be the case. I’m willing to bet that the lack of profits has less to do with having multiple code bases to maintain and more to do with the app just not being popular enough.
But all of this isn’t even my main point. To me, the thing that drives it all is customer experience. When the iPhone first came out, everything was Mobile Web. Apple then backtracked, and came out with the App Store. I don’t know about you, but I can’t think of a single App that had a mobile web or iPhone-optimized web experience that was on par with the native apps that were created. Granted, part of that was due to Edge connectivity, but the real thing is that it was all about my experience as a customer. While HTML5 is very powerful, I still don’t believe that it is going to be able to provide the same level of experience that a native application can. Yes, it can work offline and utilize local storage to make it as app-like as possible, but it’s still based on an approach that’s more about a connected, browser-server paradigm.
There will be classes of applications for which HTML5 will be just fine. I’m willing to bet many of them will be replacements for applications that are already free in the app stores. That’s an optimization for the development team, since revenues are clearly coming from another source, whether it be advertising or eCommerce. For paid applications, though, customers are paying for the experience, and if the experience isn’t as optimized as possible, there are way too many alternatives out there.
All we need to do is look back at history to know that Apps are here to stay. Java did not result in companies dropping proprietary development languages for Windows, Mac, or Linux platforms. Yes, some cross-platform products did arrive and continue to thrive, but there’s still a thriving marketplace for native applications on the major desktop platforms. Will we see many mobile applications solely available via HTML5? Absolutely, but the native app store for iOS and Android will continue to thrive.
While I’m sure the last thing we need is another analogy for enterprise architecture, a colleague of mine came up with one that really resonated with me. We were discussing principles, which many believe should represent the shared, unchanging values of the organization, in the context of enterprise architecture and governance. That’s when he came up with this analogy.
Enterprise architects need to work with the enterprise as if it were a family. If you look at a family, especially one with kids, they have their moments, but over time, they all start to embody a set of shared values.
Needless to say, I really liked this analogy. As a parent of three young children, I know exactly what he’s talking about. Now, this isn’t to say that enterprise architects are the parents of the organization, but we do need to be members of the family, more likely to be the wise elders, rather than the crazy uncle or creepy aunt.
What really works with this is that families make mistakes. They’re in a constant state of learning and evolving. Sometimes, as a parent, our goal is to do the exact opposite of something our parents did. Sometimes we want to do exactly the same thing. Most importantly, there are a set of values that we want to install in our children. The easiest path to this is to be an example of those values. We get in trouble when as parents, we contradict those values. The kids will have their moments, because they’re still learning. The same holds true in an enterprise. Individual projects may contradict the values, but it needs to be seen as a learning opportunity rather than strictly a compliance and punishment issue. When the leaders contradict the values or the values are simply unclear, the entire organization is at risk of being dysfunctional.
The role of enterprise architecture is one of ensuring that the enterprise is one big happy family. Sometimes we have to make a sacrifice for one member of the family. Johnny is heading off to college, so perhaps family vacations or other discretionary spending gets cut. While this is really of immediate benefit to Johnny, the decision embodies the family’s values of education. Sometimes Johnny’s little brother Tommy has to wear Johnny’s hand-me-downs. Sometimes we have projects that are of high priority and they get the focus. Other projects may have to reuse things created by other projects. Enterprise architecture needs to be the support for those decisions.
Update: In the twitter conversation that has followed this post, the roles of family therapist and parental guidance have come up. This also came up in my original conversation with my colleague. In my opinion, parental guidance, at least regarding architecture, should be filled by EA and it must be an employee. An outside consultant will never embody the values of the organization, they aren’t a family member. A family therapist, on the other hand, can be provided by a consultant or by an employee. The therapist’s job isn’t to tell you what your values are, their job is to help you identify your own values, and help you identify things where your actions are inconsistent with those values. Normally, if the parents are doing their job, therapy isn’t needed. Parents set expectations up front, and keep an eye out for behaviors that don’t embody the values. If behaviors need correcting, they get corrected through a variety of techniques, whether a carrot or a stick.
I’ve been doing some work recently on architecture principles and their associated implications. According to TOGAF 9′s documentation on architecture principles, implications “should highlight the requirements, both for the business and IT, for carrying out the principle – in terms of resources, costs, and activities/tasks. … The impact to the business and consequences of adopting a principle should be clearly stated.”
In the effort to define our implications, I’ve started to see two categories of implications emerge. The first is behavioral implications. These implications are functions or processes that the organization must adopt. The second is architecture/design implications. To illustrate this, use a very simple principle: standards-based. The statement for this principle merely states that all solutions must be compliant with company standards. A behavioral implications for this is that someone in the company must maintain a list of company standards. Another behavioral standard may be that the company must follow the work of standards organizations relevant to the business. An architecture/design implication would be that messaging interfaces must adhere to published company standards.
I’m finding that it may be worthwhile to explicitly define these categories in documenting the principles. One big reason is to avoid overemphasizing the architecture/design implications. It is very easy to strictly think of implications as the foundation for your assessment framework, but an assessment framework, in my experience, is typically associated with architecture and design reviews. It says nothing about reviewing the behavior of the organization, which all too frequently can be the greater challenge. For example, a reusable service may exist, but it doesn’t get used because the organization “supporting” it may see supporting other consumers as a secondary priority, at best. This isn’t a design issue, it’s a behavioral issue.
One additional thing I’m also considering is how to assess whether or not the thinking behind the implications is correct. If the rationale for a principle is that total cost of ownership will be lower, are we actually measuring whether this winds up being the case based upon our level of adherence to principles and their implications?
How would you categorize your implications? Does this two category breakdown make sense, or are there additional categories needed?
In her IT Business Edge blog titled Enterprise Architecture Paying off at Del Monte, Loraine Lawson writes:
Enterprise architecture (EA) befuddles me. As far as I can ascertain, it began as an IT function, but at some point, it was decided that EA is bigger than IT and really needs to work with the business as a business function. … I’ve had my doubts about EA, even though I’ve written several times about how the discipline can reduce integration work.
I thought I’d respond to these statements from the blog. First, regarding the thought that EA is bigger than IT. While some may argue that the original definition was always about more than IT, it’s certainly true that in practice, the focus was almost always within IT. The reason, however, that it needs to become more of a business function is that IT needs to be a business function, rather than being simply viewed as a support organization where things are thrown over the wall. This is also exactly the reason why Enterprise Architecture is a necessary function.
In a pure support scenario, you do what the customer asks, period. You can try to sway the customer, but that’s a risky proposition. Everything is constrained by the definition of the project. In such a culture, decisions that may be beneficial when viewed from the perspective of multiple projects and multiple systems are extremely difficult to make, because they are outside of the control structure (the project) that governs all of the IT activities.
Coming back to Enterprise Architecture, part of the reason it needs to be viewed as a business activity is to change the decision making process around how IT activities are defined. If this process doesn’t change, then IT can only make the best of the hand it has been dealt. Low level technology decisions, such as servers, operating systems, and programming languages, can be handled solely within IT, but as soon as you get into functionality and capabilities, it becomes far more difficult.
In my opinion, the way to do this is through a practice of portfolio management, which I believe needs to be at the core of an enterprise architecture practice. Portfolio management isn’t a one time application rationalization effort, it’s an ongoing discipline that must be integrated into the decision making process for what activities (projects) take place. I’m not referring to project portfolio management, I’m referring to application portfolio management and technology portfolio management. If we do an effective job of this, we better understand the boundaries and dependencies between the capabilities that need to be provided. By better understanding these, the task of integration becomes easier, because it’s a forethought rather than an afterthought.
It’s surprising that this focus on application and technology portfolio management is such a struggle. After all, concepts of portfolio management are well accepted in the financial world. It is a far more risky venture to just blindly purchase financial products that hot today, rather than taking a structured view of your entire investment portfolio and the goals you wish to achieve. But, alas, IT is a very project-driven culture in most organizations, and it is going to take time to change that. Many organizations have reached a breaking point where a one-time application rationalization effort is taken. If your organization is in this position, however, a one-time effort is only a short term fix. Business leaders must not only fix the current situation but also make the necessary changes to ensure it is does not happen again, and I believe a healthy enterprise architecture practice rooted in a disciple of portfolio management is one of those changes needed.
Panel discussion. Panelists:
Eric Christian, Director of Global Architecture Security at Cummins
Sandy McCoy, Executive Director, Business Architecture, Kaiser Permanente
Michael Balay, AVP, Technology & Operations, Enterprise Architecture, MetLife
Moderator: George Paras
Q: Inspiring an EA team is a challenging activity. If you had one bit of advice to an aspiring EA leader, what would it be?
Sandy: There’s an outward leadership component and an inward leadership component. From the outward perspective, anyone on the team must be a leader. You operate at levels most people don’t. Emotional IQ important, and you have to be able to communicate both with a developer or project manager at one time and the CIO the next. From the inward perspective, your people must be empowered and encouraged. EA is a thankless job, you must know when your staff is having a bad day.
Eric: We have a tremendous opportunity to add value. Focus on delivering it incrementally. Focus on delivering high value in a way that the business community can embrace.
Michael: Leadership matters in every aspect of business, especially for the EA organization. Every staff member must be a leader. One of the most important things to do at each stage of transforming is to find leaders to partner with elsewhere in the organization.
Q: As a leader, when you’re looking to incrementally grow your team, what skills do you look for?
Michael: It’s about a team and having a balance of skills. I look for people with both operational and architecture skills.
Sandy: We have a minimum of 15 years of experience, through various tracks within IT to have a variation in the skill set. When you start getting into business architecture, some business acumen is becoming more and more critical. Technology is just built into the business, we are part of the DNA.
Eric: Strongest architects as of late have knowledge of the business. It’s easier to teach an architect to be an architect than to teach them the business in a particular industry.
Q: Where do architects with business acumen come from?
Eric: At Cummins, we have been looking at horizontal immersion programs. They take a horizontal assignment within the business and will hopefully come back. The same holds true for business staff to take a position within IT for a while.
Michael: The balance is going to shift toward more business architects. I always want that business architect side by side with someone who understands the implementation, though. My bias is to find business people, match them up with someone from IT, and let them learn from each other.
Sandy: One skill that I would add to the list is abstract thinking. If you have people that can really think abstractly and connect the dots, then their actual experience is not as critical. Not everyone has this ability.
Q: What size team do you look for?
Sandy: Our chief architect likes to re-organize every 6 months, but his boss tells him to stay stable for a year. You have to adjust to whatever is happening at the time. You need to have a bunch of utility players as well as some heavy hitters in particular areas.
Q: What are the best practices to organization a team?
Eric: Cummins, a couple of years ago had a very decentralized IT. Three years ago, IT was centralized, as where the architects. We have largely aligned along Technology Architecture, Solution Architecture, Enterprise Architecture.
Architecture is an evolution, a maturity process. When you move toward the block and tackle approach, you start with fundamentals (doing well with infrastructure architecture), but as you move up you look at portfolio optimization, etc.
Michael: There is no one model for EA. Almost by definition, it must be designed and tailored to the circumstances of the enterprise. Collaborate with other leaders. Enterprise Architecture must be responding to the strategic events of the company, and may not be able to steadily climb that maturity curve. Groups that do, may be too inwardly focused.
Sandy:If you look at it as a role, rather than an organization, very rarely do we play the role of an Enterprise Architecture. As EA, we can play any of the roles, and we get pulled down into various levels of the architecture depending on the needs of the organization.
Q: How do architects split their time between strategic and tactical work?
Michael: A peer of mine worked on a very successful, strategic architecture for technology integration and services. This year, he’s continuing the effort, but driving down into the implementation of it. At different periods we need different skills.
Michael: This is how things worked at Cummins a year ago. Each of the architects focused on quite a bit. They became spread to thin, weren’t focused on the right things, and the value was marginalized. We made a separation between solution architecture and enterprise architecture to create focus on both areas, and this yielded far more traction.
Sandy: It depends how your mission statement is defined. We have 13 different divisions and they each have a different opinion on what we should be, plus the CIO has another opinion. Set some metrics on what you’d like to do.
Michael: We’re struggling with refocusing. There are too many strategic things out there.
Eric: One of the first things that was negotiated with my boss was the vision and mission. That became the contract. If business partners think something else, we come back to the contract.
Q: How do you demonstrate the value of your EA program? How do you make the investment decision for a tool like Troux?
Michael: We implemented Troux standards in 2-3 months. We were re-instantiating AIG standards. We didn’t have to reinvent the standards, but we did need to reach out to the international community. Traditionally, the review process came very late in the effort. We worked with the PMO to push up the visibility of the project to early in the process, especially so EA had visibility. If managers got involved early, 9 times out of 10, the went through the process very smoothly. We turned the traffic cop into a value proposition.
Eric: We have seen value delivered in a body of analysis work that we have done. Most things have Oracle under the covers. We had our best year ever with an excellent growth trajectory. The value comes into play with trying to balance continued growth of new plants with a strategy for managing the instances of Oracle apps.
Q: What should our audience be paying attention to?
Sandy: Social networking and mobility. People who grew up with it, want and expect collaboration. On the mobility side, everyone wants a little “app” for a piece of the business. Information and data governance becomes much more critical because it is now exposed in places where you may not want it to be.
Eric: Server, app, and desktop virtualization, mobile technology, and SaaS and cloud.
Michael: Mobility, BYOD – bring your own device, Collaboration systems on a new scale, IaaS and virtualization. In the governance space, issue is that we’re already too slow for our customers.
Speaker: Michael Pemberton, Enterprise Architect and USAA
USAA has had an enterprise architecture practice on the technology side and is now establishing a business architecture practice.
First point: Why did USAA take the journey? They realized that without a business-driven, integrated enterprise architecture, it would be like driving without a map.
Their challenge was that they are trying to increase their revenue and the membership, but at the same time, reduce their operating ratio. They needed to reduce the complexity and operating friction within the organization.
For them, being too close to the Enterprise Strategy team was a problem for their Enterprise Architecture team. It may seem counterintuitive, but there are some pressures to keep the strategy team “clean” while the Enterprise Architecture team needed to be out there working with the community.
Models need to be designed to answer questions. The business doesn’t care about the components and representation in the model, they care about the answer to the question they asked. They aim to create visualizations for the enterprise.
USAA Opportunities and Challenges:
- No metamodel, no design!
- Architect architecture
- Business focused architecture
- Visualizations, visualizations, visualizations
- Roadmap capabilities
- Killer curves: supply/demand
They showed a visualization which was essentially a spoked wheel with member at the center of the universe. A layer out from the member was a set of capabilities, then another decomposition to the business level, and then finally a set of processes out in the business. They found the normal “box-in-box” capability view to be unwieldy for the number of capabilities they had.
They also made a commitment to never come to the business with a single taxonomy again. They needed a single taxonomy to do their work, but the business needed to see the results in their own language and taxonomies. They create taxonomy alignment, but they don’t force a single taxonomy on the entire organization.
Principles they use for their visualizations are:
- Use graphics, not words (look up InfoGraphics)
- Show context and meaning NOT context and conclusion
- Enlightenment NOT training
- if you ever show the business your model, you deserve whatever you get – and it won’t be pleasant
- Quit telling executives they should use the tool!
This was a continuation of the previous panel discussion. Speakers were:
Sean Dwyer, Northwestern Mutual
Jennifer Pfaff, Jacobs Engineering
J-P Renaud, Jacobs Engineering
Eivind Nilson, Liberty Mutual
Moderator: Chuck Keffer, Troux
Q: Where are you in rolling out your current effort?
Sean: They are trying to roll out the ability to do assessments of infrastructure, roadmaps, and then send out a system feed to the governance organization. Their goal is to only have to enter information in one place.
J-P: They are rolling out Application Optimization right now, then Alignment, then Standardization. A lot of customers at the conference do Standardization first, others indicated Alignment might be the best place to start, but for them, Optimization gave them the immediate tangible benefits they needed and put in their business case.
Eivind: They also started with Optimization and a bit of Alignment. The questions they were trying to answer led us to those two modules as opposed to Standards. They went through the data gathering process and have pretty much completed it, however there are always new things they are finding. They are about to roll out a workshop where they bring stewards into the conversation not just as the data entry point, but as data consumers in their decision making process. They are establishing an advisory board with IT and business representation.
Q: Change management is a key part of your strategy. Can you talk about a few of the most important considerations underlying your approach?
Sean: This is a lifestyle change. If you don’t embrace this and get people to feel good about it, you’re dead. They had a change management communications lead assigned to the project that assisted them in their effort. They focus on baby steps, going for the single rather than the grand slam. They also chose not to start with Alignment. If you screw up within IT, people understand what you were trying to do and are more forgiving. If you screw up with your partners/sponsors that don’t have that solid understanding, the risks are greater.
Q: What concrete steps are you taking to keep the data current, correct, and complete?
Jennifer: They are adding more data stewards, having a first governance meeting soon, and establishing the processes.
J-P: They are taking a hierarchical approach to their data steward for more effective management and allowing individuals to only have a small set of data for which they are responsible. People also have a vested interest in keeping the data current.
Q: What are the target accomplishments that you are working toward?
Eivind: They are trying to speak in terms that are meaningful to their stakeholders. They positioned their data around some simple ideas. First, a summary view of the applications that are target versus non-target for rationalization, including which ones have a specific retirement date. The ones that don’t add up to some amount of dollars. This was the potential savings opportunity by IT owner. They took the same data by business owner to show the financial opportunity available. This seems to resonate very well with the people who have seen it. They also have a report that shows planned retirement by quarter. If there’s not much from your area, someone will ask why. They are documenting the dependencies and the reasoning behind their determination of target versus non-target.
Q: In launching your initiatives, did you leverage any EA framework?
Sean: No. It was more of a cultural thing.
J-P and Jennifer: No, but they did read Enterprise Architecture as Strategy and started there.
Eivind: They did use a standard business capability model for our industry, but tailored some of the language to make it specific to their company.
Q: Did you leverage any tools like stakeholder maps to obtain buy-in?
Sean: In the roadmapping effort they reached out to department heads and IT leaders and asked them what roadmap meant to them and what value they would get out of it.
Eivind: They just tried to make it as simple as possible.
Q: How does one measure success of an EA initiative and do it in a repeatable way?
J-P: Success was when we hit the ROI goal in the business case. Once past that, everything becomes easier. They are focused on that initial program and the ROI associated with it.
Sean: They have three year plans and divisional metrics. They measure how much they save through cost avoidance and reuse.
Eivind: They measure how many applications have been retired. They are still identifying targets and getting them on a roadmap.
This was a panel discussion, consisting of:
Sean Dwyer, Northwestern Mutual
Jennifer Pfaff, Jacobs Engineering
J-P Renaud, Jacobs Engineering
Eivind Nilson, Liberty Mutual
Moderator: Chuck Keffer, Troux
Context: Today’s reality for the global 2000 CIO. The average tenure is 18 months. They need to get started fast and work fast. They face shrinking budgets, rising expectations, and a big focus on alignment with the business.
The average annual sales of a global 2000 company is around $15 billion, and on average, 4% of that goes to IT, yielding $600 million for discretionary spend. Unfortunately, 80% of that may be spent on keeping the lights on, and another 80% is already allocated to business driven IT efforts, leaving $24 million or less for the CIO that is truly discretionary.
Chuck then went into Troux’s question driven approach for driving business value out of EA. It’s focused on the questions that EA stakeholders are asking, and the decisions they need to make.
Q: What were the top three factors and/or considerations in building the business case for your 2011/2012 initiatives?
Sean: In 2010, they did a lot of pilot work in the APM space. They did some charts and graphs to show that they could add value. He built the “mother of all spreadsheets” to support this pilot work whose support could have been a full-time job. They made the decision to pursue tooling to support this, rather than the “Microsoft” stack. They then tried to align themselves with the IT business strategy, such as “simplifying the business technology environment.” It was going to be difficult to this without a robust portfolio management system.
Jennifer: They had a number of objectives. They wanted to maintain sustainability, improve business alignment, improve the IT planning and systems responsiveness. On sustainability, they wanted to avoid inventing the wheel and creating processes that would increase the amount of work they had to do. They wanted to simplify things.
J-P: He re-emphasized the sustainability point. They wanted to “operationalize” the data gathering exercise. There’s a big effort that goes into the initial data population and they wanted to make sure they had processes to keep it up to date without adding huge effort to the organization. They tried to rely on places where the information was already being entered, rather than adding a new step to existing processes.
Eiving: First, they needed a practice around application portfolio rationalization, and then had to do the rationalization itself. The insurance industry doesn’t have a tangible product, it’s a promise. Their systems are the products, then. Through acquisitions, it is painful for the business to have their products in multiple suites of insurance systems. Rationalization had to happen. They are also highly regulated at the state level and a significant effort is required to maintain compliance on every one of the systems. This impacts their agility. Second, once the team was formed, they looking into tooling, including sustainability, operationalization, and business alignment. They wanted to be able to engage the business in the problem solving in defining what the target state was.
Q: Who did you have to convince to sponsor the effort? What were their motivations?
Sean: They made a difference between commitment and motivation. They had to work with the CIO and the IT division leaders. When they did these things, it was a lifestyle change for IT. It breaks down silos and you need communication and org change to support it. They took a baby step approach, not going enterprise wide. They focused on supporting IT first, before ever going out to the business.
Q: What role did ROI play in the business case?
J-P: ROI was the business case. They don’t sell a product, they sell man-hours. Our profit margin is on the order of supermarkets. They got the ROI specifically on the application optimization piece. It was the easiest one to get hard dollars out of quickly. EA is hard to define, we used the ROI calculator, cut the value in half twice due to company conservative culture, and kept doing this until they had a value that they were comfortable making a commitment to.
Jennifer: Work with the culture in your company. You may not have to cut down the numbers as much as we did. They used Forrester data to help support their case, and ultimately, it was easy to stand behind.
Q: What was the biggest challenge you faced in building/communicating the business case?
Eivind: They felt it was important to get stewardship of the data close to the IT owners. They had to show the value to those people because they would have to commit resources to do the stewardship function. They partnered with one of those organizations and did a proof on concept with a subset of that organizations portfolio and demonstrated the reporting capabilities. That gave them a champion. It is an ongoing thing to keep that commitment, those groups have other priorities that don’t go away.
Q: How much was the business case for technology a part of your business case and what was the underlying argument for it?
Sean: Technology was a big part of it. If they wanted to have better capabilities and enhance our agility, they needed better tooling. If they hadn’t done the pilot work, however, they would not have been successful. Those pilots and POCs generated a lot of good will.
Q: What techniques did you employ in communication the business case?
J-P: They did not have to sell EA. They had a CIO come in that had previous experience with EA, who kicked off the effort to establish the practice, spending a year figuring out what it needed to be. They reached a point with EVP (Excel/Visio/Powerpoint). They generated a list of things they can do and the frequency they could have updated it with their availability with the EVP approach, and then talked about what they could provide with better tooling and did the build versus buy analysis.
Q: How involved were the beneficiaries/stakeholders in making the business case?
Eivind: He mentioned their POC and the use of the “champion” to help establish credibility. They also reached out the corporate business planning and strategy group, and got representation from them in the effort. This went a long ways to helping things out.
This presentation was given by Richard J. Reese, VP of Enterprise Architecture for Discover Financial Services.
He started by showing some of the Discover “Peggy” commercials (look them up on YouTube, they’re pretty funny) and emphasized that Discover is known for their cash back programs and their customer service.
EA resource allocation at Discover is 35% solution architecture, 24% on governance, standards and frameworks, 2% on innovation and research, 5% on IT strategy planning, and 28% on roadmaps and assessments. Rick recognizes that the emphasis on current projects is an issue. Their challenge is to move from project focus to a strategy focus, generate measurable business value, manage the federated architecture discipline, and change the perception of EA (it had been seen as a roadblock/police force).
Their approach was to build credibility through their IT metadata. They have collected data from a number of different sources throughout the enterprise, integrating it into their EA repository. They had to standardize application names, and worked with internal audit to make it happen. Out of this, they built a number of business models, including ones that mapped the IT metadata to key business capabilities. Business capabilities have short, terse descriptions and they map these to the application that provide them.
Another area for improvement was to streamline their ARB (architecture review board) process. They have a standing weekly meeting where they can tie a product name to an ARB approval number, and they worked with finance to make sure nothing was funded that did not have an ARB approval number. This echoes a previous speaker who encouraged us to follow the money. Make finance/procurement a friend of EA.
They also created an EA value log, capturing value created, costs avoided, and other traditional measures.
- Set an EA strategy with metric based goals
- Develop credibility through collecting facts
- Know what works in your culture
- Find sympathetic partners (e.g. Audit, Risk, Compliance)
- Invest incrementally
- Promote successes