Monday, February 8, 2016

Ten practical ideas for organizing and managing your enterprise architecture



Original Article By McKinsey & Company

This is another McKinsey article on IT strategy, this time specifically about Enterprise Architecture practices.  From my own experience, I can attest to the importance to several of these EA organizational concepts, which I have highlighted below and have added my own commentary to them.

The text in grey are snippets taken directly from the original article.



1. The organization of enterprise architecture should reflect the organization of the business.


-- and it helps to have architects with deep business process experience and IT savvy, especially from within the major organizations that provide the competitive advantage for the company.  That is where most of the attention should be directed. Actions for IT utilities (email, document storage, etc) are commodity decisions; corporate functions (Finance. HR, Legal) should be considered for Platform as a Service cloud opportunities.


3. The EA department should collaborate closely with the business and the IT organization.

"To ensure that the business can live with its new architecture and that the IT organization can support it, the EA department needs to collaborate closely with both by bringing them into the design process and translating complex ideas into digestible action plans."

For strategic initiatives that require new functionality, the EA team must be engaged early in the evaluation cycle to determine if the existing application base has unused capabilities that can be brought to bear to satisfy the new requirements.  In these critical business functions, the emphasis should be on effectiveness before efficiency.  Non-strategic business functions should be relegated to efficiency decisions-- this should prevent purchasing new applications for marginal new capabilities in non-strategic areas.


5. The company should give the EA department approval rights.

"Companies should give EA departments more responsibility for certain big-picture decisions-for instance, approving new IT-related projects or changes to the technology landscape. Otherwise, the policies and guidelines the EA department develops may never gain traction across the company."

If you don't give the EA staff some teeth in enforcing the agreed-upon architecture, you might as well abandon the EA concept entirely.


7. The company should analyze and measure the effects of enterprise architecture on the business.

"There is no simple formula for measuring absolute impact, but one feasible approach might be to analyze the effects of enterprise architecture within a small pilot project, using business-specific metrics that account for interdependencies-for instance, how many applications and how many point-to-point interfaces are involved in the project, how many applications are demonstrating overlapping functionally, what portion of the overall application-development effort is dedicated to integration testing, and whether management tasks are easier and less costly as a result of the pilot project."

I have some issues with this statement, which is obviously directed more at EA staff start ups.  I think there are a few basic metrics that should be the domain of any Enterprise Architecture staff, since by its very definition is a broad view of the architecture.

  • Number of business capabilities and their correlation to business strategy
  • Number of applications/instances and their correlation to business capabilities
  • Number of integrations and integration technologies
  • Age and type of the infrastructure and underlying utilities – and the IaaS alternatives
  • Platform adoption (including SaaS and PaaS) to minimize applications and integrations
  • IT Total Cost of Ownership

The COO, CIO, and head of the EA staff can decide which KPIs to prioritize based on business needs and EA maturity, but some combination of these will lead to the appropriate direction for the alignment of business and IT strategy.



8. The EA department should keep it simple.

"Our conversations with EA professionals suggest that most are still focused inward; they tend to spend twice as much time talking with suppliers, for instance, as they do with C-suite and other business leaders. Instead, they should develop new ways to translate difficult concepts for the latter group-for instance, framing a discussion of potential changes to the enterprise architecture in the context of the new business capabilities enabled or new efficiencies gained."

This is THE challenge.

First, make the topic of conversation understandable and relevant-diagrams and pictures obviously help, as do business analogies.  Make good use of diagrams that illustrate the transitions (including timelines) from the current state to future states.  For the C-level audience, do not overly complicate the diagrams; you can add those when discussing the details with the IT staff and business SMEs.

Second, the diagrams should help the dialog turn towards actions- since that is what VPs and directors want to see- and that must include lists.  Lists of what assets you have, why you have them, who uses them, where are they, how much they cost, when are they going away.  Most importantly, lists that will highlight actions to needed to provide new capabilities for critical business functions while simplifying the overall IT environment and increasing its technological flexibility.  Which takes you back to the KPIs outlined in #7 above.

You can read supplemental information and anecdotes about several of these topics embedded within The Clear IT Architecture case studies.

You can read the entire McKinsey article HERE.


Good reading,
Nathan

Translate

RSS Feed