Kristian Hjort-Madsen recently posted a blog entry about the future of Enterprise Architecture in the government. Having done some work on architectural simplification for several public sector clients, this got me thinking about not only the future of EA in the government, but the future of EA in general.
It is my belief that we need to rethink Enterprise Architecture from being something that is focused on understanding the Enterprise to something that is focused on delivering value to specific projects. To some extent, this calls into question the name, "Enterprise Architecture", but I still think the name has value because it implies that we are considering project level issues that can only be addressed at the enterprise level.
To go even further, the main value that "Enterprise Architecture" can deliver to projects is in reducing their overall complexity. There are a number of secondary issues on which we can also focus, such as improving business/IT communications, but I believe that most of these will greatly benefit just from reduced project complexity.
Why do we need to focus on complexity at the Enterprise Level? Why not the IT level or the business level? The answer to this requires an overview of the Science of Simplicity. This is a bit much to cover here, but is the topic of my last book, Simple Architectures for Complex Enterprises and numerous white papers at my web site. In brief, simplification requires a good understanding of both synergistic relationships (which are best understood by the business side of the enterprise) and strong partition boundaries (which are best understood by IT side of the enterprise). We can thus only address these issues at the juncture point between business and IT, and that juncture point is what we usually call "Enterprise Architecture".
I think that government is perhaps the area that can particularly benefit from a focus on simplification. Government projects tend to be highly complex and often involve multiple vendors. When complexity is not managed methodically and early on, failure is too often the result. An excellent example of the problems inherent in such projects is the UK NHS system known as NPfIT (National Programme for Information Technology). This system will likely cost 50-100 billion dollars, and most likely will end up in failure. Why? Catastrophic complexity.
Why is complexity such a problem? Several studies (and numerous personal observations) have shown that increasing the functionality of a system by 25% increases the complexity of the system by 100%, unless steps are taken to manage the complexity. This means that taking a system from 10 functions to 100 functions increases the complexity by over 1000 times! Clearly this is not acceptable. The only way we can dampen this increase is by focusing on the problem of complexity. And Enterprise Architecture is where we have the opportunity to do so.
So let me summarize my thoughts on where Enterprise Architecture needs to go in the near term, especially in the public sector. First, it needs to move from an enterprise focus to a project focus. Second, it needs to narrow its focus to those problems that can only be solved from an enterprise (that is, a broad business/IT) perspective. Third, it needs to hone in on the one major problem that can only be solved from an enterprise perspective: complexity.
If we, as Enterprise Architects, make these adaptations, we will start making important, measurable project contributions and delivering highly visible short term value. And, in doing so, ensure our own long term survival.
Thursday, October 30, 2008
Tuesday, October 21, 2008
Can an EA be "correct"?
In a recent blog, Nick Malik asserted that EA is not about building apps right, but is about building the right apps. And that the correctness of an EA was a point of view.
This was my response:
In my view, EA is not about either building apps right OR building the right apps. It is about creating a structured framework within which meaningful and collaborative dialogues can occur between the business and IT groups. The term that I use to describe this "structured framework" is Enterprise Architecture.
In most organizations, "meaningful and collaborative dialogues" between business and IT do not occur. You must ask why this is so. Is it because the business folks are overly demanding and unreasonable? Is it because the IT folks are unable to understand what business is saying?
In my view, the problem is neither the business nor IT. The problem is that EA has either not been done at all or, if it has been done, has been done incorrectly. Which brings us back to Nick's original point. Is there a "correct" way to do EA?
The answer is absolutely, yes. But the starting point needs to be an understanding of what we mean by "correct". I define "correct" as "as simple as possible". So of two EAs that both accurately define the enterprise, the more correct one is the simpler of the two. And the EA that is "absolutely" correct is the EA that is the simplest possible EA.
Why do I believe that simplicity is the raison d'etre for EA? The answer goes back to my original question. What is it that gets in the way of meaningful dialogues between business and IT? In my opinion, what gets in the way is complexity.
When IT blames the business for fuzzy requirements, IT is wrong. When the business blames IT for inability to deliver, the business is wrong. The problem is neither IT nor the business. The problem is complexity. Until complexity is solved, dialogue is impossible. Complexity is the enemy, and it is the common enemy of both IT and the business.
So can you determine if an EA is as simple as possible? Again, the answer is yes. But to do so requires both an understanding of the mathematics of complexity and a rational process for testing an EA for being "as simple as possible".
These are both topics I have covered extensively in my book, "Simple Architectures for Complex Enterprises", so if you are interested in these ideas, that is where to go. I also have a number of papers on this topic at my website, http://www.objectwatch.com/.
Best Wishes,
Roger Sessions
This was my response:
In my view, EA is not about either building apps right OR building the right apps. It is about creating a structured framework within which meaningful and collaborative dialogues can occur between the business and IT groups. The term that I use to describe this "structured framework" is Enterprise Architecture.
In most organizations, "meaningful and collaborative dialogues" between business and IT do not occur. You must ask why this is so. Is it because the business folks are overly demanding and unreasonable? Is it because the IT folks are unable to understand what business is saying?
In my view, the problem is neither the business nor IT. The problem is that EA has either not been done at all or, if it has been done, has been done incorrectly. Which brings us back to Nick's original point. Is there a "correct" way to do EA?
The answer is absolutely, yes. But the starting point needs to be an understanding of what we mean by "correct". I define "correct" as "as simple as possible". So of two EAs that both accurately define the enterprise, the more correct one is the simpler of the two. And the EA that is "absolutely" correct is the EA that is the simplest possible EA.
Why do I believe that simplicity is the raison d'etre for EA? The answer goes back to my original question. What is it that gets in the way of meaningful dialogues between business and IT? In my opinion, what gets in the way is complexity.
When IT blames the business for fuzzy requirements, IT is wrong. When the business blames IT for inability to deliver, the business is wrong. The problem is neither IT nor the business. The problem is complexity. Until complexity is solved, dialogue is impossible. Complexity is the enemy, and it is the common enemy of both IT and the business.
So can you determine if an EA is as simple as possible? Again, the answer is yes. But to do so requires both an understanding of the mathematics of complexity and a rational process for testing an EA for being "as simple as possible".
These are both topics I have covered extensively in my book, "Simple Architectures for Complex Enterprises", so if you are interested in these ideas, that is where to go. I also have a number of papers on this topic at my website, http://www.objectwatch.com/.
Best Wishes,
Roger Sessions
Subscribe to:
Posts (Atom)
