Enterprise Architecture is not Solutions Architecture

For many years, there was confusion in the architecture community between EA and solutions architecture. For example, I remember one of the agencies that I worked at putting together a request for proposal for contractors to develop an EA for some new systems. But it wasn’t EA that they were actually looking for; they really wanted a solutions architecture to automate some particular processes (but at the time they didn’t know the correct terminology or really understand the distinction).

However, the distinction is important and the Federal EA made major strides in this area in December 2006, when they released the FEA Practice Guidance that laid out the differences (and hierarchy) between Enterprise, Segment, and Solution Architecture.

• (At the highest level,) Enterprise Architecture is scoped on the agency, at a low level of detail, with impact focused on strategic outcomes, and the audience is all agency stakeholders.

• Segment Architecture is scoped on individual lines of business (LOB), at a medium level of detail, with impact focused on business outcomes, and the audience is the line of business.

• (At the lowest level,) Solutions Architecture is scoped on specific functions and processes, at a high level of detail, with impact focused on operational outcomes, and the audience is users/developers.

Why is this important?

From a user-centric EA perspective, all stakeholders benefit from a clear delineation of responsibilities: An overarching plan and governance is provided from the Chief Enterprise Architect (the strategic layer); a roadmap for the lines of business is served up from the program managers (the logical layer); and project solutions are developed by the technical staff (the physical layer).

Al three layers of the architectures work synergistically together for the end-user, by the lower levels aligning to and complying with those above, so that specific solutions fit into the line of business roadmap for enhanced business outcomes, and the LOB roadmaps, in turn, are aligned with the overall EA target architecture and transition plan for the organization.

Do you distinguish between Enterprise, Segment, and Solutions architecture?

Enterprise Architecture is not Solutions Architecture

EA and Principles of Communication & Design

User-centric EA is about providing decision makers with not only the relevant information they need (i.e. current, accurate, and complete), but also serving it up in an easy to understand and readily accessible format.

To accomplish this, user-centric EA provides clear principles of communication and design. These include the following:

• Focus on enhancing decision making
• Develop useful and usable information products and governance services
• Simplify complex information
• Classify information into consumable chunks
• Unify information by consolidating it and creating a common look and feel
• Maximize use of information visualization (visuals, graphics, charts, and so on)
• Provide accessibility through multiple robust delivery mechanisms (so users have the information when and where they need it)
• Distinguish Enterprise from Segment and Solutions Architecture (to be discussed in a future blog)

By articulating and adhering to these EA principles of communication and design, you will greatly further your ability to deliver on the promise of user-centric EA.

Do you use similar principles of communication and design in building your EA?

EA and Principles of Communication & Design

Is Strategy or Operations King?

Strategy (read EA) and operations are two sides of the same coin — both ultimately seek to provide service and support to the end-user — and both are critical to making IT “work” as a functional whole.

In the Wall Street Journal, July 30, 2007, a number of prominent CIOs weigh in on the future of these two facets of IT.

Frank Modruson, the CIO of Accenture, predicts that within ten years, “you will see CIOs focus even more on strategy, whereas operations will be industrialized and outsourced…”

Similarly, Steve Squeri, the CIO of American Express, foresees that “the days of tech leaders as relationship managers and ‘order takers’ will go by the wayside… technical architecture will become a core function of IT departments.”

Both CIOs provide compelling visions of strategy and architecture playing an ever more central role in the enterprise for meeting business needs.

Do you agree with their visions? How important is EA in your organizations?

Is Strategy or Operations King?

Why Harry Potter Loves EA

Harry Potter loves User-Centric EA, which is all about making order out of chaos.

No, EA is not wizardry, but it can be “magic” to an organization in need of structure, process, and governance.

Before implementing user-centric EA, the enterprise often looks quite disconcerting and in a state of disarray. I’ve seen organizations before EA, where they don’t know what systems they have in place, what hardware/software they are using, what information requirements they are trying to fulfill, or even what functions and outcomes they are working toward achieving — and hence the fear and panic when the dreaded “data call” comes down.

In transforming to user-centric EA, there is a lot of hard work including discovery and analysis, building structure and process, and developing realistic plans. There is also organizational resistance — a long standing nemesis of EA. In time, as the user-centric EA journey progresses, sensible change begins to overcome fear and resistance. At that point, we begin to have structure and process take root, and we learn what we have in the enterprise, where things are located, how many we have, and how old they are. With this knowledge and with a functioning governance process, we are armed to better plan for refresh, recapitalization, and modernization — and help to build an ordered path ahead.

Similarly (oh come on, it’s not that big a stretch), Harry Potter starts out a miserable and lonely boy living an upside down life — he is even forced to live in a cupboard under the stairs in his relative’s home. He is downtrodden by all. That’s until he is transformed by his learning and adventures at Hogwarts School where he becomes a skilled wizard and a mensch, develops meaningful relationships, learns what’s what in his life, and finally overcomes the evil Lord Voldemort, his life-long nemesis. Harry’s is a journey that spans from an early life in turmoil, through numerous hardships and self-discovery, and finally, overcoming many obstacles, he can pursue a way ahead for a life of love and future growth.

Why Harry Potter Loves EA

Is SOA like Legos?

A “service” is a repeatable business task. In Service Oriented Architecture (SOA), applications are built by assembling shared, reusable, modular services into automated business processes.

In SOA, applications development shifts from technology-driven with a focus on functions and features to business-driven with a focus on business processes and services.

SOA aligns well with user-centric EA where business is the driver for technology, rather than technology for its own sake.

In the Wall Street Journal (July 30, 2007), Meg McCarthy, the CIO of Aetna, compares SOA with Legos: With Legos, we have distinct pieces that can be joined and formed into a functional object and then can be taken apart and put together again in a different way, for another use. Similarly, in SOA, we have loosely coupled services linked for use in discrete tasks, and which can then be linked in alternate ways and reused for other tasks.

In SOA independent, interoperable software can be searched, discovered, and exchanged/shared. Thus, integration is achieved by invoking service calls for necessary information and functionality.

One example where we can benefit from integration and sharing is in government in today’s post 9-11 world, where inter- and intra-agency information sharing is vital for law enforcement and defense readiness.

SOA leverages modularity and component reuse to achieve a more agile IT environment that can more efficiently automate business processes and integrate our silos of people, process, and technology.

Have you seen any examples of SOA in action?

Is SOA like Legos?

EA Modeling is Key to Business Process Improvement

Modeling & simulation has been hailed as a national critical technology and vital to national economic leadership (Source: Congressional Modeling and Simulation Caucus).

Models are representations of real world phenomenon and are static (while simulations are dynamic).

In EA, models are used to represent business processes, data and information entities, and IT systems. These models can be unified into representations that detail all the following:

• Business processes required for mission execution;
• Information requirements to supports these business processes; and
• IT systems that serve up the needed information.

In user-centric EA, models are done not just for the sake of representing these realities but are done to improve organizational performance and results by the end users. Models are central in analyzing problem areas and identifying gaps, redundancies, inefficiencies, and opportunities. The desired outcome is business process reengineering and improvement, ensuring vital information flows to end-users when and where they need it, and to support these with information technology solutions that helps us perform better, faster, and cheaper.

User-centric EA acknowledges that models are static. However, EA models need to result in dynamic corrective actions to an organization.

To really get the benefit of these modeling efforts, they must be conducted throughout the organization, in all lines of business. Unfortunately the reality is that this is a heavy lift and requires extensive commitment of resources and resolve.

Are models critical in your EA efforts? How do you use them?

EA Modeling is Key to Business Process Improvement

EA and the Singularity

One of the many definitions of EA is that it provides for a current, target, and transition plan for the organization.

However, for those of you familiar with Kurzweil’s Singularity, EA planning looks increasingly challenging.

According to Ray Kurzweil, the famous IT futurist, technology changes at an exponential growth rate. In The Law of Accelerating Returns (2001), Kurzweil states, “There’s even exponential growth in the rate of exponential growth.” Kurzweil predicts that within the 21^st century, technological change will have hit such a rapid pace that we will reach “the singularity”, where machine intelligence will in fact, surpass human intelligence and all sorts of unbelievable technological achievements will ensue.

While we haven’t reached the singularity yet, the rapid pace of technological change is a reality we are all familiar with. In this environment of rapid change (and as Kurzweil would argue, ever increasing rapid change), it will be increasingly difficult to keep up and effectively perform EA.

As EA practitioners, we need to think about what it means to “get our arms around” the target, if we cannot effectively anticipate what the target will even look like given the rapid pace of change.

Of course, from a user-centric EA perspective, we must continuously imagine and envision our future state — for the sake of our end users — so that we are the masters over our future (and not just slaves to it).

EA and the Singularity

Where does EA belong in the enterprise?

Typically, EA is a program situated under the Chief Information Officer (CIO) i.e. in the Information Technology department. However, to maximize its effect on the end-user, EA should be elevated to a strategic mission-business functional area of the organization, for example under the Chief of Staff or similar such prominent function.

EA should be elevated in the organization because generally, it will have more impact for the benefit of the end-users, which is what user-centric EA is all about. It will have more impact because:

• It will be easier to capture and analyze information in the organization, because EA has a broader mandate and vantage point from which to conduct its activities.
• It will have the ears of executive management and therefore be in a better position to implement its recommendations and plans.
• It will be better able to synthesize business and IT information, because it will be functionally independent and will not be seen as biased or simply an extension of the CIO.
• It will be able to focus on identifying the information requirements from the business side of the house and to drive technology solutions from the IT side.
• Business will drive technology (rather than investing in new technologies for their own sake i.e. because they are new and “cool”), and therefore IT investments will align with business outcomes and improved organizational performance.

What do you think ─ should EA be part of the “IT shop” or should it be somewhere else in the organization?

Where does EA belong in the enterprise?

IT Governance—Make it a Benefit for the User

Traditionally, IT governance is viewed by the end user as an impediment to getting their IT projects done. It is seen as another opportunity for the IT department to say no or to throw up obstacles. The perception is that governance is a cover for the IT department’s own inefficiencies or inability to get the job done, lack or resources or know-how; or is due to the subjective whims of the IT senior staff and CIO.

However, in user-centric EA, governance is a help (not hindrance) for users in developing and implementing successful IT projects. The way user-centric EA does this is it manages governance, bringing together the enterprise’s subject matter experts from both the business and IT sides of the house and applying their collective knowledge and best practices to facilitate IT project success.

In user-centric EA, it’s not about saying yes or no -- although of course that is inevitable in approving projects, prioritizing them, and allocating funding -– but rather it is about achieving best value from limited resources and ensuring those investments are successfully deployed.

In user-centric EA, IT governance is implemented to meet the needs of the user community and IT stakeholders -– to help make IT projects a success!

Do you use user-centric IT governance? Or is this just a pipe dream?

IT Governance—Make it a Benefit for the User

Why was Human Capital left out of the Federal EA?

What’s missing in the Federal Enterprise Architecture (FEA) is the Human Capital Reference Model. The Human Capital perspective is critical in a user-centric EA.

In the FEA, there are five basic reference models that translate into EA perspectives (or views of information):

• Performance: Measurement of strategic and business outcomes
• Business: Functions and activities that drive performance
• Information: Information needed to perform the mission-business of the enterprise
• Services: Applications and service components that fulfill information requirements
• Technology: Underlying hardware and software that supports service delivery

Additionally, while FEA looks at security as a cross-cutting architecture perspective, I like to call it out as its own EA perspective (for emphasis), particularly in a defense or law enforcement environment.

Finally, to the point, human capital are the people and organizational entities that conduct both the mission-business and technology functions of the enterprise. John Zachman, the founder of modern-day EA included people (or the who) as one of the perspectives in the Zachman Framework. This makes intuitive sense to me.

In order to focus on meeting the requirements of the EA end users, we need to provide for a view of people in the architecture itself. For example end-users need to know who are the key players in the enterprise. Users also need to understand how they align to mission execution and how they will be measured for results. The enterprise and the users need this to build a sustainable high performing organization.

Why was Human Capital left out of the FEA?

Would like to hear any thoughts or opinions on adding a human capital perspective to FEA.

Why was Human Capital left out of the Federal EA?

How EA Benefits the Organization

Even though user-centric EA benefits the user, the big winner is the enterprise. EA helps us functionally, as follows:

• To plan better for IT refresh, recapitalization, and modernization
• To make better investment decisions
• To analyze problem areas and uncover gaps, redundancies, inefficiencies, and opportunities
• To drive business process reengineering and improvement
• To ensure information needs are met
• To deliver technology solutions that meet requirements
• To communicate, inculcate, and provide clear documentation about our enterprise

Technology-astute organizations know that user-centric EA is an elixir for much that ails their IT function.

Interested to hear from anyone on other organizational benefits…

How EA Benefits the Organization

How EA Benefits the End-User

In user centric EA, business drives technology rather than technology being implemented for technology’s sake.

In an EA where business drives technology, the end users benefit in the following ways, they:

• Understand better how technology aligns to the mission
• Are able to access information transparently, where and when they need it
• Operate freely, without stovepipes getting in their way
• Leverage applications that are interoperable, not standalone
• Use simple, standardized technologies
• Spend money more efficiently on the technologies they use
• Are confident that the information they have is accurate and secure
• See mission results from their business and technology investments

How EA Benefits the End-User

EA Owns Structure, Not Content

In user-centric EA, the EA program owns the structure of the information, not the contents. On the other hand, the business programs and technical subject matter experts own the contents of the EA, and are responsible for ensuring that it remains current, accurate, and complete.

In my agency, we have institutionalized these EA roles and responsibilities as follows:

• EA Product Stewards are the EA team members that develop and maintain the structure of the information products. The stewards are responsible for understanding user requirements, designing information products to fulfill these, facilitating the capture of information, analyzing and cataloging it, serving it up to the user through robust delivery mechanisms (such as EA website, handbooks, CDs, and so on), and keeping the information under strict configuration management. In these ways, the stewards ensure the products are relevant, understandable and accessible to the end-users.

• EA Product Coordinators serve as the content managers and approval authority for new and changed information in the architecture. The coordinators are responsible for participating in the development of the agency’s EA and ensure ongoing updates as new information becomes available. In this way, the coordinators ensure that the information in the EA stays relevant to the end-users.

By having these complementary roles of product coordinators and stewards, for developing and maintaining the EA, the users are assured useful and usable information for their needs.

EA Owns Structure, Not Content

In A Nutshell, Know Your Users

At the end of the day, user-centric EA is about focusing on the user!

We have know who they are, communicate with them, understand their needs, and work to fulfill them.

As this cartoon shows if we don’t read our users needs correctly, then the result is “starship enterprise” architecture rather than genuine user-centric EA.

(Source for Cartoon)

In A Nutshell, Know Your Users

Make It Accessible - Rule of Thumb #5

Finally, Rule #5 is make it accessible.

EA information is a wonderful tool, but to be valuable to the end-user it must be accessible to them when and where they need it. Therefore, you need a robust delivery mechanism for the information.

At our agency, we provide EA and governance information in multiple delivery channels. For example, the EA information is provided through a knowledge portal on our website as well as through printed handbooks and so on.

Our EA website homepage has our knowledge center that is the navigation mechanism to get to all product information in the repository. The information is available to users 24/7.

Make It Accessible - Rule of Thumb #5

Separate Forest From Trees - Rule of Thumb #4

Rule #4 is separate the forest from the trees.

What this means is that we provide the users EA information in various levels of detail that is tailored to their particular needs in the organization. Moreover, each level of information is drillable (or clickable) to the next, so that user can navigate between information views.

For example, in our agency, we use a three level metamodel representing high, medium, and low, or what we call, profiles, models, and inventories.

• Profiles are high-level, big-picture strategic views of the information; it’s the satellite view from 30,000 miles up, providing information to the executive in a quick, condensed format, usually a graphic.

• Inventories (or catalogues) are the detailed views of information usually in database or spreadsheet format, that is typically used by the analyst. It’s the trees versus the forest; the distinct configuration items with lots of information about each one.

• Models are the connection between the forests; they illuminate relationships between information that is especially useful to the mid-level manager working with his/her peers. These relationships include those that show how processes work, how information is exchanged between entities, or how systems interoperate.

In user-centric EA, it's not one size fits all!

Separate Forest From Trees - Rule of Thumb #4

Show, Don't Tell - Rule of Thumb #3

Rule #3 is show, don’t tell.

•This means that a picture is worth a thousand words. It’s all about using information visualization effectively.

•For example, in my agency's network profile, we show a graphic of the United States. We show the nodes on the map, each representing a major communication hub. We show alignment of these nodes to the agency's districts. And finally, we show the connectivity between the nodes, including the type of communication lines.

•This network profile can be used, for example, to envision connectivity being disrupted, whether through man-made or natural disaster, and how this would affect mission execution. This is a tool for helping us plan for continuity of operations.

Show, Don't Tell - Rule of Thumb #3

K.I.S.S. - Rule of Thumb #2

Rule #2 of user-centric EA is Keep It Simple, Smart (Person).

Executives and decision-makers are busy people and do not often have the time or patience to decipher what you are trying to say. That is why we need to keep things straightforward and focused!

For example, in my agency, we have our Business Profile, which identifies our major functions. It is categorized into three, simple, color-coded functional areas (core mission, mission support, and business support).

• •Under Core Mission, we have the mission programs of the agency (such as Search and Rescue, and Defense Readiness).
• •Under Mission Support, we have the functions that directly enable the performance of core mission, such as logistics management, command control and communications, and training.
• •Under Business Support, we have the back-office functions, such as finance, HR, legal, public affairs, etc.

We use this simple graphic as a starting point for understanding what we do, who we are, and what our organizational identity is.

I have presented this to senior executives in the agency and have received kudos for taking the functions of a large, multi-mission maritime organization and making it simple for anyone to understand.

K.I.S.S. - Rule of Thumb #2

How To Do It Right - Rule of Thumb #1

From my experience, there are a number of ways to transform your EA into a user-centric model. In this post I will talk about the first one: Have a clear value proposition.

Remember, doing EA because "it's the law" (Clinger-Cohen Act) is not focusing on the users!

One example of a clear value proposition is that "EA will improve our IT planning and governance" (and thereby enable better decision making by the end users).

It was not until I started speaking in these terms that anyone in my agency would give me the time of day.

How To Do It Right - Rule of Thumb #1

What is User-Centric EA?

Well, this is exciting...my first blog, dedicated to a subject that I am passionate about - user-centric enterprise architecture.

Let's start with some basic terms:

• Enterprise architecture (EA) is the discipline that synthesizes key business and technical information across the organization to support better decision-making. EA includes the development, maintenance and use of an as-is, to-be, and transition plan. Together, these serve as the blueprints for modernizing and transforming an organization to meet future mission capabilities and requirements. The goal of EA is to improve information technology planning and governance.
  

• User-centric EA focuses on providing useful and usable products and services to the end user. In user-centric EA, information is relevant, easy to understand and accessible. In contrast, traditional EA is user-blind because the focus is on developing "artifacts" that are often unintelligible. Therefore, in traditional EA, users often have difficulty understanding the as-is, to-be, and transition plan.
  

What is User-Centric EA?