Season’s Greetings from EAdirections

From all of us to all of you, wishing you a joyful Holiday Season and a happy and prosperous New Year!

Getting Started with EIA – Identify High Level Information Classes

Recently, we have discussed the HL classes for Business Archtiecture (functions, processes, services) and Application Architecture (application classes and platforms) and Technology Architecture (domains and components).  Now let’s turn to Information Architecture, not Data Architecture.

In order to get started with Information Architecture, you need to identify all of the major “things” that your business produces or acquires information about.  We will call these information classes.  They are not databases or objects or  attributes.  They are conceptual in nature, but they represent the major entities that your enterprise requires information about.  These typically include entities such as customer, supplier, product or service, orders, items, employees, facilities, and inventory.  Of course, each enterprise may have their own language.  For instance, a financial services company may call their products by a different name, such as policy or account or fund.  And public sector organizations may not use the term customers, but rather citizens, constituents or voters.  And those in the healthcare related businesses would say patients.  In any case, you are primarily concerned with the group of people the enterprise is providing a service or product to, the sources of those products, and the major entitities involved in the production, stocking, logistics, ordering and delivery of said product or service.  You may have subclasses, as well, but for the purposes of getting started, we suggest no more than one level of decomposition.

Once the High Level Information Classes have been identified, they become more meaningful to EA work once you map them to the functional heirarchy and application classes. For more information and examples related to this type of information mapping, please see our Jump Start materials.

Views in Enterprise Application Architecture

Enterprise Application Architecture (EAA) is typically the second-most mature and well-defined area of EA, after Enterprise Technology Architecture (ETA).  Makes sense, as applications are seen to be the responsibility of the IT group as much as the infrastructure.  ETA is often described/organized in terms of domains (i.e. server, middleware, network, database), while EAA is often organized by application class (back office, customer facing, operations, etc.).  However, recently, we have had several companies wondering how to establish standards for the EAA when they are essentially taking a portfolio or functional view of the application environment. 

In order to address that need, I want to add one element for your consideration.  That is the notion of “platforms” – not the way it is typically used as a domain name – such as server platform, mainframe platform, etc. – which is usually a hardware-based platform designation.  What I am talking about is sometimes referred to as pattern or configuration, but I think that the term platform is best.

You could roughly define a platform as a specific, standardized set of IT components (i.e., hardware, firmware and software) that is configured to provide a specific infrastructure capability.  From a metaphor standpoint, the platform represents what you build upon – solutions are built upon platforms, but if you choose the correct platform, you don’t have to change it, just use it.  I think the argument we are trying to make is that each individual business solution (regardless of functionality) should not require their own platform, but rather a business solution should try to leverage/conform to the existing platform that best suits its processing needs.  For instance, one portal application should be built on the same “platform” (set of infrastructure components configured to provide portal capabilities) as any other.  Another example, if Home grown apps and ERPs and other packages apps want to integrate with other apps, they should use the same integration platform (ESB, EAI, message-based, etc.).

Examples of platforms:

• ERP
• Integration (ESB, EAI, message-based, etc.)
• Application Development
• Data Management
• Workstation
• Mobile or Handheld
• Collaboration
• Workflow
• Document management
• Communications
• Identification/Authentication
• Storage Management
• Portal
• ERP

Some of these platforms may be visible to the business community (handheld/mobile, ERP, collaboration) while others are more like technical platforms (storage management, security, data management) that support other platforms.  In any case, the platforms have a few characteristics that I think are important to note:

1. The components of a platform tends to cross the traditional technical domains.  For instance a platform is likely to have hardware, data management, network, middleware, and other software components that come from multiple domains.  This provides a basis for collaboration across domain teams.
2. The platform provides a cross reference between application and infrastructure views.  An application uses one or more platforms, while the platforms employ components from multiple infrastructure domains.  Again, this provides a basis of collaboration, this time between the application community and the infrastructure community. 
3. The platform view tends to be more consumable by a non-technical audience.

In the end, the technology domains are useless by themselves, but once you define the platforms, now they are a goal for the technical community (infrastructure, data and application professionals alike) and consumable by the application development and integration community, as well as the basis of communicating the output/benefits of IT architecture.  Really when you think about it, this is the root of EA – providing standard adaptable platforms of components already architected to meet the enterprise’s needs upon which specific business solutions can be assembled to meet specific business needs.

EA Value Contribution

What value does the EA function provide to the enterprise?  That question consistently ranks in the top ten list of most frequently asked EA questions.  The question, unfortunately, doesn’t lend itself to a simple answer.  It is more often a matter of value being in ”the eye of the beholder”.   In other words, the answer to the question depends on who is asking and what answer they expect to hear based on their personal and professional interpretation of the word “value”.

A systematic, multi-part approach to addressing the value question can lend clarity.  By classifying the various ways that EA groups contribute value, and identifying the stakeholder communities and how they align themselves with those classifications,  each organization can address the value question in terms that are meaningful to their particular stakeholder mix.  In our experience every organization always has multiple value expectations. 

The weighting among various value contributors differentiates one organization from the next.  The weightings will change as the EA function grows and evolves.  To begin to answer the value question, lets define three possible value contribution classes.  These are focused not on what an EA function is, but on what it does for the enterprise:

Project Support:  In some organizations, value is defined exclusively by an individual’s direct contribution to the completion of project-oriented tasks.  While one can argue as to what proportion of individual EA team member’s time is directly or indirectly linked to project tasks, and it will vary by role, skill set and EA maturity, in the aggregate every EA team interested in long-term survival must make their contribution to project completion visible.  After all, it is the rare organization that doesn’t perceive “getting things done” as the highest value component.  As EA teams evolve, contribution to project success will become less hands-on, design-oriented and become more “guidance” oriented as the EA team uses its collective insight into the future state and roadmaps to inform project activities.  In these cases, getting things done “right”, in consideration of both project and enterprise requirements, becomes the operative value contribution.

Strategic Direction: The “raison d’être” of an EA group is to understand the strategic direction of the organization and capture it into a future state representation that reflects the eventual achievement of that direction.  For leaders that believe in EA, their expectation is that the EA organization will invest resources in creation of go-forward standards, patterns, platforms, models and other representations.  After all, an EA team cannot effectively and efficiently perform their “support projects” value contribution if they don’t have a basis to use in providing guidance.  Therefore, creating useable and prescriptive future state guidance, and communicating those directions to the project and asset communities, is a key value contribution that must be included in the mix.

Portfolio Transformation:  It is a rare organization, indeed, that doesn’t suffer from the accumulation of past incremental additions to its asset portfolios (technology, solutions, information, etc.).  Each addition was, at the time, fully justified and sensible in the context of the problem they were trying to solve.  Only upon retrospective analysis does an organization discover the burden those portfolios place upon them in the form of cost, resources, or inflexibility.  Given the future state holistic perspective defined by an EA function, a significant value contribution of EA is to help guide portfolio transformations to shed excess or duplicate components and bring them into alignment with the go-forward wishes of the organization.

By analyzing how the EA function can contribute in each of these categories, and by thoroughly understanding the expectations of stakeholder communities in each, the EA team can strike a balance that will satisfy itself that it is doing the right things, and demonstrate it to leadership as well.