EA and Portfolio Management
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.
3 Responses to “EA and Portfolio Management”
Leave a Reply
I couldn’t have summarized the situation with current EA thinking better Todd.
I personally learned this important lesson the hard way after seeing peers and predecessors fail year over year. More than ever, I’m seeing EA practices in organizations maturing quickly as real enterprise change agents that are sustainable, results oriented and measurable. I firmly believe the secret to these more recent successes is when combining portfolio management techniques with traditional modeling. And yes, the business is now getting more involved these days too, as Enterprise Architects re-orient their language to that of portfolio and business terms rather than showing models or alienating folks with framework debates.
The critical factors that we have learned when working with customers is that portfolio management concepts are imperative when implementing a sustainable EA practice. Organizations that manage EA practices with portfolio management techniques get to value more quickly and start to realize benefits of their program, compounding value as the practice matures. As a result, practices are evolving more quickly, even new EA teams starting from scratch are seeing benefits that are unprecidented in more traditional EA approaches. Sucessfull teams tend to report on their success in increments of weeks vs the months or years that traditionally plagued EA efforts.
Anyone that has worked on a multi-year, transformative effort in a large complex organization may recognize that simply modeling future states isn’t really enough to track and measure the effort effectively for the enormous scope and timescales involved. I learned this fact early in my Enterprise Architect career, choosing a more radical approach than those of my predecessor attepts. The major change this time was to augment a traditional end-state architecture effort with portfolio management practices, combining efforts to create a new ability to manage all the key effected portfolios long-term.
The portfolios we needed to track in my case were certain technologies being phased out, applications being consolidated or re-platformed and business processes being affected. Only when we properly managed the portfolios were we able to properly quantify and communicate the effort over time in terms that our executives understood. This was a hard lesson to learn since few of my peers were able to offer guidance, tools and techniques, nonetheless it was invaluable lesson that re-oriented my thinking about EA entirely. I realized what my real contribution to the effort was, and it wasn’t in delivering the transformation itself. I eventually learned that the effort would long outlast my career within the company, perhaps even outlast my lifetime. Focusing on providing the organization a way to track and measure beyond the shadow of doubt that we weren’t really making a dent year over year . The reasons for the halted progress were revealed when we added up all the smaller, seemingly disparate decisions being made. The net effect as effectivelt stalling the effort, which was only revealed when measuring the impacted portfolios. Individually, each trade-off decision seemed rather insignificant, but cumulatively we knew the truth. As a result of our new insights, the organization was able to make better decisions that still yielded multiple millions in savings and cost avoidance.
So I challenge other Enterprise Architects out there to begin measuring your success not only by delivering large, complicated transformatations, but to also up-level your organizations abilities to manage these efforts and be better prepared for the next one. If you don’t focus on maturing your EA practices to incorporate portfolio management techniques, your competitors will beat you to it and leave you behind.
Hi Todd
I’d be interested to know what kinds of things you include in your capability portfolio. Are they just lumps of software (aka applications) and lumps of hardware (aka technology)?
I’m particularly interested in those strategic management practices that are not purely IT but are critically dependent upon IT, such as the capability of an enterprise to customize its products and services to specific customer requirements, or negotiate efficient and flexible supply contracts with its business partners, or to collect and interpret business performance data. These are areas where EA may be able to contribute usefully to improving the collective intelligence of the enterprise.
Do you see these capabilities as part of the EA portfolio? How far do you think EA should go in helping to manage and improve this kind of management capability?
#entarch #orgintelligence
Thank you for addressing this. I do think EA makes sense. In reflecting more, what I think is the hard sale is a new position called enterprise architect. I’m just not sure how you convince the business when many of the basic, underlying business value has already been promised (and evidently not delivered) by other IT roles, such as the CIO and CTO. So, enterprise architecture, yes, but I’m wondering if how you can convince the business to support “promoting” a job title called EA out of IT.