EA Voices

As terminology for the practice of Enterprise Architecture has evolved from Enterprise Architecture to Enterprise Architecture Management or in our (Troux) case Enterprise Portfolio Management, I occasionally hear the term “IT Planning”.  Although IT Planning per se is an important clog in the strategic IT management wheel, it alone is insufficient to a successful Enterprise Portfolio Management (aka EA) program.

Conventional theory defines management as a set of interconnected processes: Plan, Organize, Control, and Direct.  Planning — here too —as you can see is necessary but not sufficient on its on own for successful strategic IT management

Likewise we can think of Enterprise Portfolio Management supporting a set of interconnected processes that include “planning” but extend well beyond to ensure strategic IT management decisions are made with a recognition of the other interconnected management processes.

The IT Management Processes

Enterprises have invested in their current IT management systems (e.g. ITSM, ALM, PPM et al) to support a wide variety of IT processes.  Today most of these processes are siloed within a particular system, but in fact if we step back and take a “big picture” view of these processes it is possible to identify a set of interacting management value chains that span IT in its entirety.   These value chains can be characterized into five fundamental management processes as shownin Figure 2.

1. IT Change Management: The objective of change management is to
   ensure processes are defined for  efficient and prompt handling of all changes to IT infrastructure, in order to minimize the number and impact of any related incidents upon service (paraphrased from Wikipedia).
2. IT Portfolio Governance: The processes of managing the risk, health, standards, and compliance of the IT assets such as technology, applications, and information.
3. IT Demand to Delivery: The process of managing the investment portfolio including business demand, funding, solution architecture, governance, and delivery.
4. IT Financial Management: The processes of IT financial budgeting, measurement, reporting, and forecasting.
5. Business and IT Planning: The process of business and IT strategic planning and roadmapping.

These value chains do not exist independently, but instead create a value network through their interactions.  Figure 3 depicts an example showing how they might interact.  For example, in this case a new business need identified in the Business/IT Planning value chain drives budget needs in the IT Financial Management value chain resulting in a new program request in the Demand to Delivery value chain that needs to be coordinated with investment needs (for example an application modernization need) coming from the IT Portfolio Management value chain – hence Planning is not enough.

Enterprise Portfolio Management comprises of a broad set of rich information sources and a number of interacting value chains and processes that are each dependent on the other.  It is clearly a complex system and due to that complexity it can be chaotic and subject to the “IT butterfly effect” where small changes in the environment can have unexpected and potentially disastrous  results. 

The purpose of Enterprise Portfolio Management is to give insight into the interconnected nature of these portfolios and value chains in order to manage the chaos.  That certainly goes well beyond the requisite “IT Planning”.  To quote an ancient saying: “Planning without action is futile, action without planning is fatal.”  EPM delivers both planning and action.

For more information on EPMs role in the IT Management process click here http://www.troux.com/solutions/ .

Six years ago I posted a blog article called Solution Architect Skills Idea. At the time, I was a practicing Solution Architect pushing the boundaries to mature the Solution Architect discipline. I built the Solution Architect Skills Assessment to help organize the skills I felt were necessary to be a world class Solution Architect and used it to mentor folks interested in growing their Solution Architect skills. The skills taxonomy was later used to help form IASA’s Solution Architecture skills profile which, I think, is still used today. Funny, I still get contacted regarding help with Solution Architecture skills because the Excel workbook I used to store the skill information was passed around with my name still in the document author properties. Because of the viral use of the skills taxonomy and feedback from folks tell me how useful it was, I consider it a pretty good success.

Anyway, a few years ago, I shifted professions into a Business Architect role and have learned tons. I now know enough through learning from business management experts and through my own practical experience that I feel comfortable helping others in the area of Business Architecture. I’ve even begun to accept a few mentees and am using the Business Architect Skills Assessment to shape their learning roadmap. The feedback is very positive so I thought I’d share it on my blog. Keep in mind that it is only a start that needs maturing. I’ll try to keep it current with my personal copy as time goes on.

I hope the Business Architect Skills Assessment proves useful to you too: Gabriel’s Business Architect Skills Assessment workbook