Real EA's Don't Wear Ties

The title underscores a reality of the state of Enterprise Architecture. Stereotypically, "real EAs" are senior, Mountain Dew-drinking, software developer's that cut their teeth on death marches during the dot-com glory days. These folks would not ever think about wearing a tie. A new-age EA is emerging however - the business professional with as much background in business management as technology. These folks are far more likely to wear ties. Hence the dichotomy - tie or no tie? An alternate title for this post could be:


Pick Your EA: Enterprise Enterprise, Enterprise Software, or Enterprise Technology?

With several hundred replies and counting. Kevin's Smith's challenge on LinkedIn to define Enterprise Architecture in a 160 character text message underscores one thing. There is no agreement on what it means to be an EA. Here's my shot at describing EA and the value it adds. No comment on whether we should were tie (but I do.)

Defining "Enterprise Architecture" (Again)

One of the biggest challenges facing EA is defining itself. Because EA works broadly across IT and the business, organizations should clearly understand and acknowledge EA's role. Lack of clarity causes organizational friction resulting in wasted effort and under achievement. Conversely - when an organization truly understands and leverages EA, it can save $Millions by getting where it needs to be efficiently.

Regardless of your definition, EAs are senior, experienced and costly resources. Without clarity, EA is often characterized as a bunch of highly-compensated, very experienced people who do all sorts of things that don't cohesively contribute to the business' mission. Many EA organizations have roots as a team of technology experts too senior to be placed full-time on one project; in many cases, the "Enterprise Architecture" team was established to manage this pool of very senior technologists.

Is EA Just a Group of Senior Technologists?

We get to my point and the subject of the remainder of this post: Is EA just a group of senior technologists leased out to projects or who walk around with their head in the clouds pontificating about the "enterprise"? Or is there real business value in this senior team that grew up in technology?

Since I struggle communicating what I do to friends and family; and my boss has the same struggle with his peers and senior management, I offer a definition and an example. Possibly this will help EAs get a bit more clarity on the value we offer.

A Definition of Enterprise Architecture

Enterprise Architecture (verb) - the application of proven architecture techniques to complex organizations for the purpose of helping the enterprise efficiently meets its objectives.

Enterprise Architecture, at its heart, reconciles a number of competing forces into a cohesive body of knowledge that provides an actionable set of governance artifacts in support of effective decision making.

[compare this to several other definitions on wikipedia which are also enlightening]

So, what the heck does this mean?

• I did not mention technology, underscoring my belief that EA begins and ends with business. EA has its roots in technology because the referenced "proven architecture techniques" began as Enterprise "IT" Architecture (term credited to IBM) as a means to reconcile competing stakeholder concerns in complex, "enterprise class" software applications and environments.
• The techniques developed in Enterprise "IT" Architecture, such as IEEE 1471-2000, and TOGAF can be applied to organizations as a whole to achieve similar benefits, document different stakeholder concerns regarding a complex organization into distinct viewpoints, and then reconcile them back together into a plan that can be governed.
• Architecture is about taking complexity and figuring out what to do. It is about creating a blueprint of a future state and a plan to achieve that future state. Often this involves a definition of your current state, a high level building plan or "roadmap" and a governance mechanism.
• Most important, EA produces "stuff" to help decision makers make the right decisions. Therefore if your organization has an EA team, and the products of that team are not supporting the people making organizational resource decisions, you are not realizing the full potential of EA.

Rewriting the EA definition in noun form -

Enterprise Architecture - a body of information that reconciles competing organizational forces and perspectives into a cohesive enterprise blueprint and roadmap. The Enterprise Architecture supports making the tough decisions necessary to get from where the organization is now (current state) to where it wants to be (future state) in an efficient manner. At the end of the day it's about investing limited resources in the right people, process, financial and technology changes to move to a desired state.

It is a law that I'm sure some Ph.D. has named - the larger an organization is, the more difficult it is to act in an efficient and cohesive manner manner (1). Put more simply, the bigger you are, the harder it is to move. That's where EA comes in and where the final part of this blog picks up - an example of a project with and without proper EA.

An Example

Our example involves the ACME Company that sells financial products. The company executives have established strategic direction that the company should be more customer oriented and also more operationally efficient in how it collects the money it is owed.

Sans EA, the IT planning and delivery team is likely to seize this strategy and, being planning and delivery people, come up with a very good application to deliver - a single billing system replacing 12 departmental ones, and providing a web interface to make it easy for customers to see and pay their bills on line. What could be better than this!

The idea makes the business very happy and technologists are pleased because of the technology consolidation. Initial response is so good that a project is immediately funded. Strategy and planning hand off to a project team that refines this idea into a concept, analyzes delivery alternatives, and, oh yeah, let's get those architects involved so we use the right servers and software systems to build our nifty new application.

Flash forward twelve months - the company has been unable to lock down requirements and accurately estimate the effort. $Millions have been spent with a consulting partner to define the application concept, roll up some preliminary capabilities and capture a consolidated set of requirements and define a technology architecture that will support these requirements. Successively increasing estimates to completion have eroded the originally conceived benefits to the point that the funding committee has cancelled the project. The company is not happy, technology still has 12 applications on aging technology and a significantly swollen and blackening eye socket. Some heads roll down the hallway. So exactly what happened?

Some obvious finger-pointing targets are lack of disciplined requirements by management and estimating staff. Another target is the business case and benefits estimating practices. However, even if these areas are very mature, the best possible decision would have been to pull the plug much earlier. Enabling ACME to make the right decisions so it could could achieve its goals is exactly what its EA team should be doing.

Let's look at some of the hidden problems and what EA could have done to help:

• Problem 1 - there were 12 different billing applications because the company had grown by acquisition over the last 10 years. Billing and collections processes were still established and managed by departments that were responsible for different products sold to different market segments. Some were located in the home office, some billing centers operated in other locations. The Enterprise Business Architecture deliverables should have documented this current state and defined a future state in which a consolidated, efficient single billing system could operate; with these deliverables to guide, executives might have realized the extent organizational and process consolidation was needed before a single system could be implemented. Instead, the project suffered from requirements creep as the project team tried unsuccessfully to make separate billing business processes fit into a single application.
• Problem 2 - Billing data was scattered across the 12 applications; the project architects understood this and the plan was to cleanse and consolidate this data into a single source of the truth. This became problematic for two reasons - first, the billing data needed to be properly coded for reporting and compliance reasons, but the project team did not anticipate the amount of organizational agreement between billing, finance and sales that would be necessary in order to consolidate 12 different coding schemes (literally 1000's of codes). Second, the volume of data created by consolidating all this billing information into a single reporting data store far exceeded the project estimates for storage and the maturity of the organization's reporting technology. Because of this, the technology architecture of the application kept changing; there were too many unknowns. The delivery date kept slipping while estimates to completion increased. An Enterprise Data Architecture should have not only identified redundant data, but also the underlying standards issues that were the root cause of the coding problems. Enterprise Technology Architecture deliverables should have identified the underlying technology gaps in reporting and storage management. All this could and should have been done prior to or at project inception by an architecture team with an enterprise perspective.
• Problem 3 - The billing application estimates implicitly assumed the company's financial management systems were far more mature and capable than they really where. The business case and solution architecture were developed by the billing portfolio team which was separate from the finance portfolio; the dependencies between the systems were not documented. As the project moved through its definition phase, and the detailed requirements of the financial systems were identified, it became increasingly apparent that either the billing project would have to include an overhaul of financial system interfaces or several in-flight financial system projects would need significant acceleration and increased budgets in order to support the single billing system. Enterprise Application Architecture deliverables should have identified the current state and future state of the financial system's to a sufficient level of detail so that the billing architects could have quickly seen that the necessary interfaces did not exist.

How could this have gone differently if an Enterprise Architecture team had been available and properly functioning? Instead of handing off the business strategy to the IT planning and delivery teams to "fill the order", application of some architecture techniques to this enterprise's desires should have uncovered the problems and suggested a roadmap. To steal a bit from the Gartner Enterprise Architecture Framework, the EA should have led the business through an analysis of its Business Change Requirements to understand where business changes (organizational alignments and processes) were needed BEFORE technology could successfully deliver an application.

Wait, you say. Couldn't most of these problems have been avoided if the project team had just been more thorough in its analysis at the beginning of the project? The answer is yes; but...understanding and documenting the complex relationships between the business, data and technology is what EA, according to my definition, should be doing. That's why you have them. So if the project team had identified the business process consolidation problem as an issue, it would be doing EA! Which is great, because EA doesn't have to exist as a separate group. Continuing....

Enterprise Architecture's expertise in decomposing complex systems into component parts and identifying relationships would have enabled an understanding of organizational structure and process as it relates to the ability to deliver technology. EA's knowledge of the business would have allowed it to advise on the need to solve organizational issues before investing in technology. Similarly, the EA team should have identified organizational issues with data reconciliation and standardization as key predecessors to achieving the company's strategy. Finally, current and future state enterprise solution models should have identified gaps in the necessary interfaces between billing and finance needed to achieve the desired goal.

Had ACME been fully leveraging its team of EAs as a connector of business strategy and IT investment, it would have followed a roadmap of projects to reorganize the business of billing, establish billing data coding standards, acceleration of its financial systems projects and incorporate billing data requirements into financial systems interfaces. The EA deliverables at worst could have avoided several million dollars of wasted investment by delaying the billing project until the organization was ready for it and at best could have increased IT credibility by enabling partnership with the business in creating an enterprise roadmap necessary that move the business to better customer relations and improved management of its receivables.

In conclusion -
If you've stuck with this blog up to this point, I sincerely hope for the following:

• You agree that you don't have to be a Java developer to be an good EA - in fact, the more you know about your business, the better you are.
• You understand the potential EA represents to significantly help organizations get to where they want to go.
• If you are an EA and have a desire to learn more about the business as a part of what it means to be an EA; or if you are from the business and all of this stuff makes sense and is interesting to you, come over to the "dark side", we need you in EA.
• If you're a business or non-EA IT Executive, start talking to your Chief Architect about how EA can function as described here.
• If you don't agree and you are still reading - tell me what you think. After all - this stuff is just IMHO.
• If you're friends or family - this is what I do! :-)

---

(1) - think its burried somewhere in Anthony Kelly's Decision Making Using Game Theory, but haven't got very far into it yet.