EA Principles Have Little Value

Just recently I learned that a client’s CIO leadership team began a detailed and substantive discussion on EA principles, the implications they carry for their organization, and how they can use them to transform their journey into the future.   I don’t see this as often as I’d like.  While gaining that level of leadership engagement in the creation and use of EA principles has long been a desired outcome, it is still somewhat rare.  In this case, it was a combination of good luck, good timing, and a skilled Chief Architect who was able to keep principles visible and to broker the discussion with leadership.  There is a lesson to be learned here.

With common sense as a significant part of a good set of EA principles, it is easy for a leadership team to write them off as “a statement of the obvious” and not pay much attention.  As enterprise architects, our goal must be to make principles relevant.  The approach is for us to demonstrate how they are used in practice and to show that they are more than a collection of catchy phrases.

For each principle individually, and for the set as a whole, it is important to be able to explain them in real-world terms.  This means choosing principles that guide desired behaviors and explain their rationale and implications in a form that leaders can relate to, with an emphasis on how they affect decision-making at all levels.

Unfortunately, I see many examples of principles that don’t gain traction.   When that happens, EA principles have little value.   When I diagnose the situation I often see that a lot of energy was consumed in creating the perfect written words, with less energy committed to bringing the principles to life.

A few tips:  Always be sure to include rationale and implications, but don’t worry so much about making them perfect, just strive to make them good enough.  Invest the extra energy in bringing them to life in four ways:

1. Ensure that ALL members of the core and extended EA teams understand what the principles really mean and how they are used
2. Be sure to actively and visibly reference the principles in the process of creating future state EA content
3. Refer to the principles and use them as a test in ALL solution architecture and coaching work
4. Carry the principles with you in discussions with leadership at every opportunity

By using the principles every day, their value will eventually be self-evident and leadership teams will recognize them as a helpful tool in their management arsenal.

Did We Forget about Adaptive EA?

Lately, I have been wondering in my dealings with clients, prospects and online forums if we have forgotten this most basic, but important goal of EA – adaptability – the ability to accommodate change quickly and easily.  Complexity and the rate of change continue to increase, but the focus of many EA groups seems to be more focused on accommodating particular focus areas – major projects or business areas.  While much of this is because we are in a more tactical arc of the pendulum swing right now due to the economy and resource constraints, it is important to maintain a focus on enabling change while we work on specific domains or initiatives at the sub-enterprise level. 

There are two elements that are crucial to an organization creating and maintaining an adaptive environment – standards and governance.  Standards provide a common place to start – whether they be infrastructure standards like standard vendors and products for hardware and middleware; or application standards like coding standards, common integration practices or reusable components; or data standards like common metadata, naming standards and authoritative sources.  But in addition to defining these standards, effective governance must be in place to ensure that the standards are applied, especially in times such as these where there is immense pressure on project teams to deliver value and results as quickly as possible.  It is actually times like these that demand EA and governance to be most effective – when there seems to be an organizational push to eliminate anything that might delay project delivery.  This is when EA, IT and enterprise leadership must continue to place adaptability as a primary goal for planning, design and implementation.

I have some other ideas on this area as well, so see my other post this month for more.

Is EIA the Key?

As organizations continue to struggle with the complexity and amount of change to deal with, the EA team plays a crucial role in laying a foundation of adaptability for the organization to build from.  Once an organizations has done an acceptable job of providing a standardized infrastructure and at least basic governance of infrastructure standards, focus tends to shift towards the application portfolio and integration approaches.  This is natural and seems to conform to most of the evolutionary models of EA, such as the one from MIT Sloane CISR in Enterprise Architecture as Strategy.  However, I would like to provide you with an alternative to consider as I see organizations continually struggle with business units demanding more uniqueness to the functional systems they need to run their part of the business.

I think the key for some organizations to achieve a more adaptive environment is to focus on architecting the information and integration environments.  If information was more standard and consistent BETWEEN information systems with a common integration architecture (standard methods, components, messages, and middleware), then the information systems themselves could be unique functionally.  The architecture would need to provide the means of translating information formats and content from systems into the standard format and content for sharing outside the system.  This would also support SOA approaches, cloud computing strategies, mobility, and other approaches being pursued today.

As an EA team, are you focusing on the functionality of a specific area or are you leaving that to the project team, so that you can focus on the shared aspects of an application environment, namely the information assets and integration capability across the enterprise?

EAA Views – Portfolio and Platform

As has been stated by EAdirections and others, Enteprise Application Architecture (EAA) is generally the second area of EA to mature, following the Enterprise Technology Architecture.  As the infrastructure is standardized, the EA team looks to the consumers of that infrastructure to take advantage of the standardization – the business systems. 

As organizations begin to address the EAA, they generally take two paths to maturity.  One addresses managing the complexity of the application portfolio, called the Portfolio View.  The other addresses managing the complexity of application Integration, which is called the Platform View.

Getting started with the Portfolio View involves a focus on identifying the gaps, weaknesses and overlaps in the set of applications the enterprise is currently operating, building and planning.  Our Jump Start matrices are one vehicle that you can use to help in this analysis.  Another early activity that we recommend is a quick “Business Fit Vs. Technical Fit” categorization of the current portfolio.  Going further than the current state assessment into gap analysis and roadmapping will require some basis for identifying future state aspects of the application portfolio.  We recommend Strategic Capabilities Changes analysis. 

Getting started with the Platform View involves designing standard integration methods and configurations of technology components to provide standard service capabilities (security, user interface, data interchange, directory, collaboration, etc.) to applications of similar technical types (packaged, BI, publishing, etc.).  Common steps to develop the platforms:

• Identify the needed platforms and capabilities
• Identify the needed services per platform
• Identify existing service providers –Including duplicates
• Declare standard (and alternate) service providers.  Use cases help when more than one alternative is available.
• Bundle services into Platform Configuration Document
• Identify missing services (no current provider)
• Identify candidate (and dependent) efforts to build platform service

One of the common practices among organizations maturing their EAA is collaboration between the EAA working group and the members of the ETA working group in the definition of platforms and platform services.

CIO’s and EA – Leadership Challenges in IT

We ask a lot of our CIOs.  Just follow the myriad magazine articles and research pieces targeting CIOs to read of the breadth and depth of expectations heaped upon a single role.   The industry experts who define what CIOs ”should be” suggest that they must be technology visionaries and innovators, business transformation change agents, vendor relationship negotiators, savvy business managers and human capital performance motivators, cost-cutters, quality experts, portfolio managers, talent scouts, have operations and service management knowledge, be technology, process and solutions aware, passionate leaders and experts on the company’s industry, etc.  The list goes on.  Actually, I agree with all of these traits and more – they are all required.   It’s a tough job and can’t easily be characterized into a simple role description.    

As a case in point, I have been following Bob Evans’ column in Information Week of late.  I enjoy his perspectives.  His most recent column, “Do CIOs Still Matter“ , struck a chord in me.  He listed ten ideas to get started redefining a CIOs roles and boundaries.  Many of his points spoke to things that we have been coaching our Enterprise Architecture clients on for years.  In particular, he commented that today’s CIOs “spend too much time on the tech side of IT and should instead be more involved in technology-enabled business growth and customer intimacy”.  Other points included “lead the charge in seeing the future”, “drive transformation” and my favorite, “be a business-model buster”.

So, what is the CIO to do?  How can a CIO be tactical and strategic, responsive yet not reactionary, thoughtful and systematic yet not slow and obstructionist, operational and also transformational, cost-sensitive while investment and growth oriented?  The simple answer is that in all but the most extraordinary individuals, it isn’t possible, or it is at least unlikely that all of the required personality traits and knowledge can co-exist.  The best approach to being broad and deep enough is to surround him/herself with a strong team, with each member focused on different aspects of the role.   The best CIOs are already doing this, realizing that the CIO role isn’t intended to be a single super-human (though many white papers seem to suggest that and some CIOs try to become one) but is instead an aggregation of the skills and talents of a group. Traditionally, that group is called the “Office of the CIO”.

Many CIO’s already recognize that they can’t personally be everything to everyone and that they must have a great staff.  Most CIOs put a director in charge of the data center with a focus on operational efficiency and meeting service levels.  One or more directors are usually focused on solutions development and delivery.  The better organizations have a PMO in place to shepherd the project portfolio, though most PMO’s are low maturity engaging in mainly project tracking and reporting.  More on that in a future article.  What is missing in most CIO Offices is a person responsible for the big picture future state business context, the holistic cross enterprise perspective, the long view of the health and utility of the asset portfolio, and to address larger concerns like complexity management, portfolio optimization, integration, and the integrity of the information, technology and business architecture assets.  These activities and perspectives are embodied in the role Tim and I have prescribed to the “enterprise” architect since we began in this discipline in the 1990′s.    

While empowering a diverse IT leadership team is necessary, successful CIOs also understand that the buck stops with them, so they need to be able to make sound decisions when the rest of their staff doesn’t.  One powerful way to be sure the staff can address all the perspectives above, including the longer term, holistic enterprise view, is to elevate the Chief Architect to be a full member of the Office of the CIO.  If you have an EA function, but it is doing only the subset of enterprise architecture that we describe as “IT” architecture ( which usually means they reside several levels down in your organization)  then augment their skills and personnel and have them engage in the strategic and business-oriented discussions described above.  You will find them to be a valuable addition to your core team.

Stay tuned, we will be writing a lot more on the placement of EA in the Office of the CIO, the complimentary roles that exist in the Office, the dynamics, politics and culture of the team at that level, and the processes, perspectives, and leadership skills required for that team to support the breadth and depth of activities expected of the modern CIO.

CIO Forum in Chicago: EA Benefits Session and Panel, April 6/7

George Paras has been invited to join Leon Kappelman, Editor of “The SIM Guide to Enterprise Architecture” (a project of the SIM Enterprise Architecture Working Group (SIMEAWG)), in a session on EA benefits at the upcoming Chicago CIO Forum & Executive IT Summit to be held at the Renaissance Schaumburg Hotel & Convention Center on April 6 and 7, 2010.  

The session will describe how using enterprise architecture (EA) concepts can yield specific benefits for organizations. We explore several real world examples where starting small, or with “slivers” of the overall architecture, can win over business executives by demonstrating real value. We also show how EA capabilities can be built upon the current skills of IT staff and how organizations can develop an EA capability that provides both short- and long-term value to the organization. Session concludes with an interactive panel discussion, question-and-answer session with attendees.

I look forward to seeing you there.  If you can’t make the event, please contact me via our website contact page to arrange a time to talk about how to apply these concepts to your own organization.

The SIM Guide to Enterprise Architecture  – Edited by: Leon A. Kappelman. This book is a project of the Society for Information Management’s Enterprise Architecture Working Group.  EAdirections has been a member of this important group since its inception.  The book reflects the research, analysis and thought leadership of a rich and diverse set of contributors.  

Look for the EAdirections chapter on A Pragmatic Approach to a Highly Effective Enterprise Architecture Program.

George Paras speaks on “Enterprise Alignment through Enterprise Architecture and Governance”

I am pleased to have been invited to join Ronald Ross, Roger Burlton and many other noted speakers to present at this year’s Business Rules Forum at the Bellagio Hotel in Las Vegas.  I will be presenting on Monday, November 2 during the all-day Business Alignment Symposium and also participating in a panel discussion with the rest of the Symposium faculty at the end of the day.

Use Special Code 9SPGP when you REGISTER to receive a 10% discount!

Title: “Enterprise Alignment through Enterprise Architecture and Governance” 

Achieving ambitious, large scale enterprise transformation demands unique competencies and perspectives, different from those required for day-to-day project execution and operations.  It requires an enterprise view of alignment, bridging big-picture strategy consistently into hundreds of smaller scale implementation and operational decisions.    Enterprise Architecture (EA) and effective Governance are two of those critical competencies.  This session will explore the techniques and approaches that leading organizations use to institutionalize these core management disciplines, reaching beyond the IT department to create a true partnership with business leadership. 

• How to sort out competing Business, IT and EA priorities
• Perspectives: Strategic vs. Tactical, Enterprise vs. Project, Process vs. Content
• The Enterprise View – Capabilities, Portfolios and Roadmaps
• Alignment deliverables for the executive and models for EA consumer
• The human challenge – Culture, People, Persuasion, Roles, Responsibilities

Discipline & Knowledge: Keys To Cost Containment Assessments

The pressure on IT to contain costs is well understood. Every vendor has a presentation about how their products can be central to lowering costs.  Research companies are publishing cost containment frameworks and consultants have lots of white papers. 

Over the past several months we have worked with a number of clients to help them in their cost containment efforts.  At 50,000 feet, it appears that everyone starts with the same playbook – renegotiate with vendors (starting with your telecomm vendor), cut consultants and contracts, virtualize everything, defer some maintenance, cut travel and training…and hope that is enough (so you don’t have to cut permanent staff).  Frankly, this approach gets many CIOs down to an expense level that is “acceptable” to corporate leadership.  Many CIOs also “accept” that this approach will likely increase long-term IT costs as well as inhibit long-term business strategy. 

On the other hand, those clients who seem to make the best tactical and strategic decisions, when executing a cost containment exercise, appear to have two consistent characteristics. 

First, they are very disciplined in their approach to ensure a comprehensive review of all areas of IT costs (i.e.  IT Procurement & Asset Management, Product & Technology Rationalization, Application Portfolio Rationalization, Server Virtualization, Open Source, PC Costs, IT G&A etc.).  Even ‘un-thinkables’ are reviewed to ensure completeness, for example:

• “Are there staff who can use OpenOffice instead of Microsoft?”
• “Should we re-examine our commitment to clusters and look at horizontal scaling?”
• “What are the implications of replacing EMC with NetApp?”

 This discipline includes doing an objective and ‘truly loaded’ cost analysis.  ‘Truly loaded’ refers to being sure that all costs are fully accounted for.  For example, in looking at the cost of internally managing Microsoft Exchange and BlackBerry Enterprise Server versus a specialized outsourcing option (e.g. MailStreet) they make sure they include the cost of internal staff’s travel, training, PCs, cell bills, office space, etc. as well as the full loaded data center/support costs (e.g. Help Desk, space, storage, electricity).  It is very clear that internal IT staff significantly underestimate the ‘truly loaded’ costs of providing specific services.

Second, they make sure they have adequate knowledge to make their evaluation.  They don’t rely on speculation or anecdotes and, instead, look for hard facts and case studies.  And when they see an example they really work to understand what are the dynamics in play at companies like:

• Wal-Mart – which uses SaaS (Red Prairie) to optimize employee scheduling at their stores versus running a similar application in house
• Sabre – which executes 60% of all travel reservations in North America on a server farm using very inexpensive HP Intel servers running Linux and MySQL, which saves Sabre approximately $20 million a year in operating expenses in support of AA.com, Travelocity and several other travel-related sites

 These clients recognize that a meaningful evaluation of Cloud Computing requires an in-depth knowledge of the types of offerings available, and comparative strengths and weaknesses of each category of offering as well as the different vendor offerings in the category. These clients make sure that if they are evaluating an open source alternative to Cognos (e.g. Pentaho) that it can meet their needs.

 The bottom line is that ‘discipline’ and ‘knowledge’ are key characteristics of cost containment assessments that yield  the best tactical and strategic decisions.  (Based on our experience working with clients, we have developed a Cost Containment Workshop that helps ensure these are achieved. 

For more information on this topic and to read a description of a new IT Cost Containment Workshop check out the entry on the Education and Seminars page.

Business Architecture vs. IT Architecture

We are finding Business Architecture (BA) to be one of the most misunderstood but high-profile interests of business executives, CIOs and enterprise architects alike. They are asking questions like:

• Is BA the key to enabling business transformation through an enterprise (EA) effort?
• Does everyone have a business architecture?
• Is it owned and driven by the IT organization or the executive leadership of an organization?
• Can you truly enable business transformation with an IT-centric view of Enterprise Architecture?

For decades what IT professionals have called Enterprise Architecture is actually IT architecture. What we see most of the time is an EA effort mostly, if not solely, conducted within the IT function. There are certainly benefits to be achieved from IT architecture – improved adaptability, standardization, cost reduction, reduced integration complexity, and quicker time of delivery tend to be the chief objectives of most IT-led EA efforts. However, the lack of business participation, especially from those with strategic leadership, and the lack of distinction between BA and ITA will keep EA efforts from truly supporting or even contributing to an organization’s transformation efforts.

EAdirections is exploring three perspectives of the structure of EA from traditional to transitional to a truly transformational view. They will demonstrate how you must evolve the view of enterprise architecture as you go through different stages of maturity:

• How the Traditional View of EA supports the establishment of a strong IT foundation for the enterprise
• How the Transitional View of EA enables a more adaptive and agile foundation for quicker solutions delivery
• How the Transformational View of EA leads to true business transformation

Some EA efforts evolve to become more transformational based on the need and request of senior leadership seeking help with major business transformation. However, most EA efforts are going to have to develop the models, language and value proposition in order to get business leadership interested in architecting enterprise business transformation.

Enterprise Transformation

Looking beyond the clutter of day-to-day priorities, transformation is an ever-present and fundamental driving force for the enterprise. High performing C-Level business executives commonly have a business vision for an enterprise that is bigger, better or different than it is today. This vision yields a set of transformation goals such as simplification, cost reduction, increased agility, better service to customers, and improved quality, efficiency or effectiveness. The scope can be large or small. The approach can be evolutionary or revolutionary. The pace can be aggressive or reserved. In all cases, the “transformed enterprise” is the systematic realization of the vision. By embracing transformation as a core concept, IT executives use it to steadily guide their organization to the transformation target.