Link: http://www.biske.com/blog/?p=832
From Todd Biske: Outside the Box
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.
