CIO Expectation From an EA Practice
“Just give me the bottom line! How does Enterprise Architecture justify its existence?” As the instigator or facilitator of numerous pioneering efforts at establishing and building EA practices over the past twenty years, answering this question has been a frequent challenge.
The fact that Enterprise Architecture is a very new practice, growing out of the relatively new and highly dynamic IT industry, adds to this challenge. It is further complicated as the definition of EA and the understanding of the role of enterprise architects continue to evolve.
It is appropriate to take a check point and evaluate the value proposition for EA from the perspective of today’s state of evolution. Since almost all EA practices have been established under the wings of the CIO, let’s approach this evaluation in terms of his or her expectations of that practice.
There are three primary ways that an effective EA practice contributes to the goals of the CIO:
- By Improving the Service Delivery of the IT Function
- By Providing More Effective Governance of IS and IT Programs
- By Aligning IS and IT Programs with the Changing Strategic Needs of the Business
Enterprise Architecture Value Proposition
Interestingly, these three means of contribution: service delivery, program governance and business alignment, also represent increasing levels of maturity and capability for the EA practice with correspondingly increasing benefits.
In service delivery, the emphasis is on effective management of resources and expenditures with corresponding improvements in operational costs and service quality. In program governance, the emphasis is on risk management, ensuring completeness of impact assessment, addressing interdependencies and managing changes so as to improve the quality and timeliness of IS and IT programs. In business alignment, the emphasis shifts to leveraging investments in business transformation, focusing on strategic opportunity identification, ensuring that all conceived programs are aligned with shifting business priorities and that programs are well defined with established and measurable strategic benefits.
Obviously, the greatest benefits are accrued at the business alignment level of maturity, where the EA practice becomes a highly valued and leveraged facilitator to business transformation. This should, in our opinion, be the ultimate goal for every EA practice. Since the capabilities for achieving these levels are progressive, it is important to establish an intended timeframe and migration plan for the EA practice. Your choice of EA frameworks, methods, tools and the selection and development of your enterprise architects will be significantly affected by recognizing that facilitating business transformation is the end goal.
Let’s trace this progression through the three stages, considering the shifting value proposition and contribution of the EA Practice. As we do so, consider where your organization is currently positioned, which of the related EA capabilities are already established, and how clear your vision and plans are for the future.
How EA improves the Service Delivery of the IT function
As with any service delivery organization, the key performance metrics are:
- Quality of Service (fit to requirements)
- Cost of Service (value received)
- Responsiveness to Service Demands (timeliness)
... all measured from the perspective of the client.
Early EA initiatives attacked the fertile ground of resource management which hits on all of these factors. The unfettered investments in systems and technologies of the 70’s and 80’s coupled with the rise and fall of several competing technology architectures left a mixed metaphor of “siloed” systems connected with “spaghetti-like” interfaces which many organizations are still sorting through.
EA brought the frameworks and rigor to analyze this clutter and to tackle the rationalization of divergent system and technology investments in like capability areas. Some practices concentrated on systems rationalization (how many financial systems or order capture systems do we really need?), while others tackled the technology infrastructure (what to do with this mix of incompatible and largely proprietary mainframe, mid-range and personal computers and all of their accoutrements?)
The more advanced practices learned to do both, establishing a short list of approved technology standards to guide the selection and integration of the target systems. Where the EA team was given the power to enforce these standards and choices, significant benefits were realized from reducing complexity, leveraging vendor relationships, providing interconnectivity and allowing for timely refreshment of technologies with exponentially improving price/performance.
Roll forward to today—the same principles and opportunities persist. This season it’s all about SOA and ESBs which are the latest flavors of appeal to Software Engineers and Technology Engineers respectively. The architect’s role and value contribution is to manage the bigger picture of placing these new capabilities into the portfolio of choices, establishing the “business case” for shifting target architectures and creating a suitable migration strategy. In other words, remain focused on addressing why, how and when these new capabilities will improve the delivery of IS and IT.
How EA Provides More Effective Governance of IS and IT Programs
As the emphasis shifts from cleaning up the legacy of systems and technologies to better planning and governance of new IS and IT initiatives, we see a corresponding shift in the role of the EA practice. The focus shifts from driving out costs to reducing risks associated with new programs, while ensuring timely delivery of new capabilities.
Now the interest is in managing the portfolio of new requests in the context of the existing capabilities. System and technology architects translate business requirements into target architectures with pre-planned migration strategies and road maps. These target architectures and migration plans reflect knowledge of what exists today. They also incorporate the use of various shared integration systems such as message hubs, portals, data warehouses and workflow management systems. They reflect the use of service-oriented interfaces to improve the decoupled nature of these systems of records and their supporting integration infrastructure.
These benefits all come down to the old adage of building “better, faster, cheaper” systems that provide agility to change or expand capabilities, in response to ever-changing business requirements. Enterprise architects lead the planning for these new system and technology capabilities, ensuring the best solutions to the business requirements by providing blueprints and implementation roadmaps to the design and delivery teams. They also provide a service to the program management office by ensuring compliance of these solutions at critical design and delivery milestones in the acquisition and development lifecycle.
How EA Aligns IS and IT Programs with the Changing Strategic Needs of the Business
This ultimate progression puts the EA team and the CIO into the enterprise planning arena, getting involved in the actual determination of enterprise transformation strategies and programs, rather than being handed program requests from the business.
Now the emphasis shifts to providing a Chief Enterprise Architect (CEA) along with a team of Business Architects who identify with facilitating enterprise transformation plans and programs. Whose job is it to design the new enterprise? The complexity of today’s business, government and military environments with all of their shifting paradigms has created an opportunity to consolidate the planning functions under a common transformation-planning framework and methodology. The practice of Enterprise Architecture is readily extendible to the entire domain of enterprise planning, not just its base of systems and technology.
Advanced EA approaches, such as those we have developed at Proact, are being applied to transformation initiatives at the formative stages. Since many of these initiatives are enabled or supported by current or emerging IT infrastructures, the CEA and the EA team are able to fully align these capabilities with the strategic opportunities of the enterprise, earning a seat at the table when key strategic directions are established.
An important technique in bridging the gap between IT and the business is the adoption of an enterprise reference model that reflects the business (or program) and operational needs of the enterprise. We use service-oriented reference models to reflect these capabilities and to clearly demonstrate the linkage between business, operational systems and technology views of the enterprise.
This provides an excellent starting point for assessing current capabilities, identifying strategic opportunities and developing scenarios to describe desired end-states. All of the planning functions come together around a common set of reference models and contribute their ideas and component solutions to an already integrated model.
Consequently, as new strategic programs emerge and are approved, they are already expressed in a form that represents the architectures of the desired solutions. In this way, the CIO can be assured that IT is addressing those initiatives that are truly and traceably strategic to the enterprise.
It is for these reasons that we believe the ultimate goal for EA is in facilitating enterprise transformation.
by Art Caston
