One EA Team, Three EA Functions
In my opinion, a business function can often be best understood by describing the processes that compose it. My last post, I attempted to describe the role of an Enterprise Architect, and the ensuing discussion quickly splintered because everyone viewed the function of Enterprise Architecture differently.
So, for today's entry, I made an attempt at describing the high level processes involved in Enterprise Architecture. I did not limit my description to the bits that my team is focused on, but rather tried to cover as expansive of a view of EA as I could. As my sources for this effort, I relied on the TOGAF and various process charts available on the web, as well as my personal experience.
Not trivial. There many different descriptions of the Enterprise Architecture function, and different companies clearly implement their view of Enterprise Architecture, as a business function, in different ways.
In the end, I was able to create a single process diagram (below) that illustrates the business function of Enterprise Architecture, but only by modeling three distinct sub-functions as independently as possible. In essence, I can explain the business function of EA by explaining these three functions:
- Enterprise Architecture as Planning and Alignment
- Enterprise Architecture as New Technology Innovation
- Enterprise Architecture as Standards, Methods and Best Practices
There is some elegance to this description. I can separate the activities of these processes rather nicely. I can illustrate business value for each one, each creating a case for EA to exist. I can point to documents and frameworks that assist with each one.
| Function | Processes | Business Value |
| Planning and Alignment |
|
This function delivers strategic alignment through financial governance. By creating a vision of the future, and then insuring that funded projects help to build it, EA insures that the right applications are built. |
| Innovation |
|
This function provides a research and development organization to the CIO, allowing investment in shared infrastructure and new technologies. Without an innovation organization, IT teams devolve into "order taker" organizations. This is the only function of EA that potentially provides INPUT to the corporate strategies. |
| Standards |
|
This function interacts directly with the project-level work, either in the form of standards and Arch Review Boards (ARB), or in the form of direct contributions to the practices of a team. Best practices are shared and the teams produce higher quality code more frequently. |
I'm attaching an image of a process flow that includes Business Leaders, business groups, process management, development, and the Program Management office. If you'd like to see it full size, click on it.
The three colored lanes (yellow, green, and blue) are all part of Enterprise Architecture. The white lanes are other stakeholders. This image displays not only how these processes are interrelated but also how they are independent of one another.
Conclusion
The function of Enterprise Architecture can be described by describing three sub-functions. Any organization can implement all three functions, or a subset of them, and still legitimately claim that they are performing Enterprise Architecture. (And perhaps it is the fact that there are seven permutations that creates so many discussions that start with "That doesn't look like EA to me!")
By illustrating the interrelationships between these various process flows, the model I included provides a simplified version of the high level IT funding and delivery lifecycle. I'd love to hear what you think. Did I capture all of the things that EA does in your organization?
[note: updated process model on 6-13-08 to clarify the role of process improvement]
[note: updated process model on 6-25-08 to make it more readable]
[note: updated process model on 9-03-08 to include supporting functions]
Technorati Tags: Enterprise Architecture, BPM, IT Alignment
Comments
Anonymous
June 11, 2008
Nick, In the previous post I was thinking about Enterprise Architecture in terms of different enterprise applications and interactions between them. I wonder if systematic reuse of different works products (not code only, but rather on a larger scale such as requirements, application architecture, test plans, standards, etc.) in different applications is another function that EA should be concerned about. Or perhaps it goes under what you've identified as “Standards”. In any case, could you please comment on the role of EA relative to systematic/planned reuse of different work products across the enterprise? Thanks.Anonymous
June 12, 2008
Hi Max, We have a number of different efforts of this type within various parts of Microsoft IT. All are directly connected to the projects, because that is where the information is, and that is where the leverage lay. Only a project can generate, or use, that information. So, yes, that falls within the bounds of the "Practices" stream on the diagram above. We have a series of efforts surrounding the notion of a repository, especially as it connects to the Oslo product that will be coming out sometime next year (Do not quote me on the dates. I am unconnected with the product team). We collect requirements, services, artifacts, design elements, data elements, all kinds of thing. I don't know of a single project that has successfully pulled it ALL together yet, but some are clearly trying (including the S+S project I'm working with). Hope that helps, --- NAnonymous
June 12, 2008
I frequently discuss EA as a business function, including in my last post .  However, one requestAnonymous
June 12, 2008
Hi Nick. From your diagram I get that you are IT focused. I mean you first "evaluate IT portfolio & weaknesses" according to enterprise strategy and later (way later in your value chain) you develop (redesign, reengineering, improvement) business process that are affected by those IT projects. Shouldn't be the other way around? Strategy pulling business processes architecture strings and then getting into technology? I think that in the end EA revolves around enterprise alignment (not just IT alignment) and the development of new enterprise capabilities. I think Paul Harmon´s enterprise alignment cycle is better. Strategy Committee proposing new goals and strategies so a Business Process Architecture Committee changes business process architecture accordingly and then a IT project portfolio (infrastructure, software, etc.) is created. This way your business processes do not get submitted to technology. Where do you see the enterprise architect in this picture, in a process-led enterprise? Around SOA? That´s a very good question. Excellent stuff in your blog. Keep the good work.Anonymous
June 12, 2008
Hi Gerardo, Excellent response. Let me think about it, and look at Paul Harmon's work, and I will come back to the idea. --- NAnonymous
June 13, 2008
Hi Gerardo, I took a look at Paul Harmon's work at http://www.bptrends.com/publicationfiles/Enterprise%20Architecture%20Whitepaper-1-23-03.pdf His flow is similar to mine (he misses some critical steps). I have all of his steps, with one very important exception: I failed to include "process evaluation" in the "Evaluate IT Portfolio" step. Right now, I will reword the text, and sometime today, when I have a gap in my schedule, I'll update the process diagram to reflect. This is an excellent catch, Gerardo, and I appreciate the insight. That said, Paul's paper completely fails to describe two of the three business functions of Enterprise Architecture. People who read a paper like his, focused so completely on the "alignment" track, and who follow his advice, will fail in their EA efforts. Paul doesn't want that, and neither do I. --- NickAnonymous
June 13, 2008
You are right Nick. Harmon leaves innovation out of equation and there is no mention of architecture reviewing that you suggest. I think innovation is a labor that must be executed by everyone in the Business Architecture Committee. I see there three or four enterprise-wide experts on every architectural viewpoint that TOGAF suggests. So the Application Architecture guy must have ears and eyes fixed under technology radar related to software development. That way he can bring fresh ideas to the enterprise architecture. Given the different nature of the four viewpoints to expect that one guy knows/controls everything is not real. As for your suggestion on standards I think it is very important to have a couching/reviewing figure that somehow guarantees the adherence to EA guidelines but I would not restrict it to software alone. Business processes modelers/analysts could receive very good input from a Chief Business Process Architect for example. BTW have you seen Scott Ambler´s work? He wrote an extension of RUP (called EUP) sometime ago that I think it´s worthwhile to look at.Anonymous
June 13, 2008
The comment has been removedAnonymous
June 16, 2008
The comment has been removedAnonymous
June 17, 2008
Hi Gerardo, Sounds like you are part of an "architectural guidance committee." My take: I'd love to see an EA group pass recommendations to that guidance committee as part of the first and second business functions that I outlined above (Both Planning and Alignment, and Innovation). I don't know the size of your organization or the span of your portfolio. My gut says that, at bare minimum, you need at least one person for every 20M in annual IT project spend. This person or team would perform the architectural analysis needed to base the advice from this committee to the CIO on data and facts rather than opinion. Note: that gives you no resources for process improvement activities in the third function, a key input to architectural success. If your organization is not large, then you, by yourself, may need to perform both of these roles for functions 1 and 2. That is fine, but only if you can put in a good deal of rigor into your work and create a system of input from multiple stakeholders to make sure that you are not the only person "responsible for good ideas." (That would be an untenable position for anyone). You will also have to translate your findings into business data, in order for this committee to make useful recommendations. As far as Scott's work, I don't know why I haven't heard more... could be my problem and not his. I'll dig in more. --- NickAnonymous
June 20, 2008
Thanks for your answer Nick. I found it really interesting. Actually I am kind of making a suggestion to our management toward the adoption of an EA reference framework instead of just IT change management. With this post you helped me a lot cause I see other dimensions of EA that complete the picture (or at least enhance it). And so I have more questions to you. Is it shortsighted to see EA as a IT change management tool? Where does IT change management fits in an EA? I kind of have the answer but I would like to hear it from you. Gerardo.Anonymous
June 20, 2008
Hi Gerardo, Interesting question. I would view frameworks like ITIL and COBIT to be focused on Change Management. EA is more aligned with causing change than managing it, although the 'standards and practices' thread has some small aspects of CM associated with it. I'd say that the description I'd apply to EA, instead of change management, would look like this: "EA drives innovation on processes and technologies, insures that funding aligns with strategy, and raises the quality and effectiveness of IT efforts to create a simple, agile, and well-run information and operations environment for enterprise success." I hope that answers your question. --- NAnonymous
June 23, 2008
Now I see the difference more clearly. Thanks. Given the three main functions that EA has, is it different EA practices applied to a private and a public organization? I work for a government agency and I can see clearly planning/alignment and standards functions but innovation is not that clear. It does not mean that public sector should not innovate but it is less common ground than in private sector.Anonymous
June 23, 2008
I'd like to get a copy of the diagram I can see properly. Alas the image quality is not too good. Could you send me an image please? Then I can comment. <<e-mail address deleted by Nick to prevent spam>> [I sent Steve the diagram, and updated the blog to put a better image out there.]Anonymous
June 23, 2008
Btw, here http://www.ibm.com/developerworks/rational/library/jan07/temnenco/index.html Vitalie Temnenco shares some thoughts around EUP and TOGAF differences. I do not know if you have a policy or not of publishing data, links or whatever about your competition but he makes good points. Gerardo.Anonymous
September 17, 2008
Not long ago, I got an e-mail from someone I had not met, directed from this blog. He had used the diagramAnonymous
May 07, 2009
I'm a process guy. I'm not a big fan of the claims of process management software, but I'm a huge fan