Ref.: https://en.wikipedia.org/wiki/Cart_before_the_horse

Can EAM be the driving force to enable effective delivery of Business Strategy or is EAM just an enabler to check on the availability of various architecture resources for the development of required organizational capabilities? Should SPM be used instead of EAM to focus on key initiatives and then drive the execution of strategy? Is SPM is the tail wagging the dog or is EAM putting the cart in front of the horse? Actually, we need both and therefore must align these capabilities.

To understand the enterprise context, we should ask following questions:

• What is our enterprise purpose? What do we do and why do we do it? What is the enduring purpose of our enterprise? What is our mission? What are the values we declare, and we live by?
• What is our business strategy? What are we trying to win at to fulfill our purpose? What is driving the change? Is it inside-out driven or outside-in driven change? What are our strategic goals and objectives? What operational objectives have been cascaded down the organization and what outcomes expect executive management?
• What is our organizational capability? What do we need to be good at to win? Are we capable to innovate? Have we been able in the past to drive organizational transformation? Does our organizational culture create a climate for innovation? Does the complexity of our ecosystem destroy the business value we could deliver and extend the time to market?
• What resources can we make use of in our enterprise architecture? What makes us good and how good are we? Are we resilient and adaptable? Is our organization in the state of readiness to undergo the transformation? Do we have leaders that can take the charge of transformation? How much does legacy thinking and tools drag down our ability to deliver new IT solutions and services to support automation?  Do we have the data quality to enable the delivery of integrated information etc.?

The above items are just a sub-list of questions actually needed to establish the context for any initiatives through engagement with the right set of stakeholders. But we also need to know who will be asking these questions. Will they be able to communicate effectively with people in charge of business strategy? Will they be able to define and to deliver the vision of the transformation? What is their storytelling skill? Are those competent resources part of the Enterprise Architecture team’s, or are they part of the PMO team’s?  Should we enable the transformation through SPM-managed initiatives, delegating to EAM only the delivery of a technology strategy and roadmap to support current and future business capabilities. Alternatively, EAM could be the driving force giving us the capability to  support transformation of key stages in our value chain, leaving SPM to focus on the execution of operational objectives and initiatives?

In short, we need mature, aligned capabilities in both EAM and SPM. According to the excellent IT-CMF book from the  Innovation Value Institute, an EAM capability is the ability to envision, plan, design, lead, manage, and control organizations, systems, and/or processes in current, transitionary, and future states, and the relationships between them. Architecture conceptualizations need to consider stakeholders concerns and key requirements, support the review the current state of our application and technology portfolios, visualize the target state of architecture landscape, and to define transformation roadmap.

On the other hand, SPM capability is the ability to select, approve and balance project portfolio components (projects, programs, or sub-portfolios) to deliver the organization’s strategic objectives and its operational needs. Managing the project portfolio will prioritize, monitor, track, analyze, report, and as necessary, terminate project portfolio components that consume organizational resources, currently and planned?

If you dive into TOGAF’s ADM Phases E and F (for transition planning), you’ll see how EAM feeds the content of the SPM. Then SPM manages the implementation of solutions, while EAM performs implementation governance to assure alignment between the implementation projects and the aspirational vision of value added laid out in TOGAF’s  Phase A (Architecture Vision).

The Open Group Togaf 9.2 Figure 5-3: Interoperability and Relationships between Management Frameworks

Nowadays, in enterprises that have the ambition to become Agile@Scale, enterprise architects should also perform their activities synched with lower-level activity cycles taking place in program increment planning and iterative solution development (sprints). This means delivering MVA (minimum viable architecture) first. Then additional ADM iterations would follow to deliver new architectural increments supporting emerging design. This could mean that EAs need to wear multiple hats to also have the requisite abilities needed for implementation delivery. They should also be effective collaborators to drive design, reengineering, components reuse, application patterns, and to create enabler epics to better frame and facilitate faster and better solutions.

Being close to the development teams will mean that EAs would be visible not only in architecture review activities, but also contributing ongoing practical and tangible value for overall solution development and implementation. Enterprise Architecture institutionalization will also mean EAs would require more formal connections to business strategy to better assess the organization’s motivation to change. EAs could help by driving value stream and capability modelling, including heat mapping those elements that need strategic focus. In addition, EAs could be the segue to the better integration of other techniques, such as design thinking or customer experience mapping. 

Better integrating EA into SPM in the ways described above could help them from becoming perceived as just ivory tower architects. In the ever-changing world of digital transformation, enterprise architects should be wearing the hat of business partners who help facilitate the smooth implementation of projects with business teams. If they don’t continue to pursue and succeed at such integration, their practical ROI will be continuously questioned and their very jobs threatened.

By Alex Wyka, EA Principals Senior Consultant and Principal