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.
|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.|
||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.|
||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.
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]