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.

Who Decides?

Do you sometimes feel that your EA standards don’t carry any weight? You create them, publish them, and then when it comes time to apply them you find yourself re-justifying the standard or even justifying the need for standards in the first place? Even commonly accepted de facto standards with long histories in an organization can fall prey and need to be re-justified before each use.

It’s a very common story and it points to a fundamental weakness in EA governance. Compliance processes and design reviews alone aren’t the answer – they can often lead to accusations that you are acting like the “EA police”.  An organization needs a robust EA approval process as well.

Most organizations, regardless of maturity and for a variety of reasons, need to address/re-address the question of “who decides?” when it comes to standards, roadmaps and the overall EA strategic direction. The key to success is that some degree of meaningful standards must be decided in advance of the need to actually apply them.  Enterprise Architects, though, SHOULDN’T be the ones to decide (or enforce) standards. Why not, and if not, who should?

Independent EA authority may work for the least controversial EA decisions, but it usually won’t stand up for the big ones or when more powerful or influential leaders choose to go a different way. The root of decision-making authority for EA rests with the body that makes policy and investment decisions for the organization.

Is that practical, or even plausible? It is if implemented in a model that relies on layers of decision-making authority, with delegation pushed downward, while accountability is maintained upward to that ultimate root authority.

We’re gathering data on the level of governance involved in EA standard approval across our readers. Please take a moment to answer the attached polling question, and read more on this topic on our website. We’ll let you know how people respond in a future blog entry.

Common Step to Effectiveness – Alignment across EA Community

A common theme that seems to be coming up often lately with clients, prospects and some of the online forums I read is the gaps and overlaps that exist among the many groups involved in the EA function.  As EA becomes more effective, there tend to be more formalized groups created.  It is common for there to be a central EA team, but also working groups focused on one of more of the traditional domains of EA – business, information/data, application and technology.  

Who creates the standards?  Who decides where standards are needed?  Which teams should be involved in reviewing which projects and investment decisions?  Who models business processes?  These and many more questions will pop up as more and more groups, both formal and informal, get involved in the EA effort.  It is important to define the decision rights authority and areas of responsibility for each group.

Too many times, we see groups let these questions go unanswered and the result is as if EA no longer exists.  Instead of a coordinated, collaborative approach, the enterprise reverts back to several silos of decision makers who think they are contributing to EA.

While it is typical for the Core EA team to have a coordination role; as EA grows, this can become a monumental task as the EA Core Team is usually small and has other areas of responsibility.  So our recommendation is to document the areas of responsibility for each team involved, including non-architecture groups such as application development, infrastructure engineering, database management or IT operations, as well as the decision rights authority for each group as well. 

On a related topic, check out George’s blog entry on Who Decides?

Call to Action – Help the Online Forums Get EA Right!

Anyone else a little frustrated with the techno-oriented positioning of many of the questions and postings on EA forums?  I understand that most of us are Information Technology (IT) professionals, so it is a good source of professionals with information and experience on technology topics.  However, as we have noted many times, it is this positioning reinforcement that continues to confuse many who are new to the practice about the intended nature of EA.

While there has been some lively debate over the last year or so about the true nature and placement of Enterprise Business Architecture, there has been some relatively consistent positioning of EA over the last decade as a strategic planning discipline.  EA is positioned as a discipline (both the process, people and resulting artifacts) intended to define a long-term, business driven future state to help decision makers rationalize short term needs with long-term direction. 

Please join us in trying to be consistent in the positioning of EA.