The Architecture Of An Enterprise

Using Houses, Star Trek and a Systems View of Capability Management to Show What the Architecture of an Enterprise Is

A connection of mine Ken Evans has a LinkedIn group discussion going on in the Enterprise Architecture Network titled "What's an Enterprise?"

Ken states he knows the meaning of the phrase "the architecture of a house" because, like most people he has a very good idea of what a house is but suspects that most people have different ideas of what an "Enterprise" is.

He went on to suggest that prior to having a debate on "what is the architecture of an enterprise", we should have a common agreement on what the term "enterprise" means and asked for definitions. He makes a good point worth exploring further.

Houses & Their Variations

Houses and buildings come in all sizes, shapes and styles but the word "house" is clearly understood and distinguishable from the word "building", no matter the size, shape or style, with the exceptions some houses appear to be buildings and some buildings are used as houses.

"House" is so commonly understood there is common understanding of the wide variations in style. For example the differences between a "ranch", "split-level", "2-story", "double", "duplex" and "carriage house".

"House Style" is so commonly understood, variations within a style are easily understood and communicated, for example, differences between a "colonial", "french colonial", and "tudor".

Even variations in size, shape, style and (working) environment are commonly understood and communicated such as the differences between a "townhouse" and "single with a detached garage" neither of which is ever confused to be an "apartment over a garage" or a "french colonial estate".

Furthermore, differences in specific elements and their purposes are variations, inclusions and exclusions commonly understood and communicated with minimum resistance in mutual understanding and minimum inability to communicate it. For example elements of houses such as kitchens, bedrooms, bathrooms, etc., where for example one specific house includes 3 bedrooms and another only 2.

Or one house has a dining room, one has an eat-in kitchen and another has both. Or one has a living room, one has a family room, one has both and another has neither. No matter the differences in houses, everybody knows what a bedroom is and what the differences are with a kitchen. No matter what the combination of elements is, everybody knows what the basic and fundamental building blocks of a house are when it comes to the functionalities needed within houses.

There are even situations where multiple functionalities needed in the house are combined and this situation is commonly understood and communicated.

Differences in houses are so well understood that if the functionalities of a bathroom are (incorrectly) located within the kitchen instead of the bathroom, everyone knows there is a problem with risks which needs to be addressed.

As when it comes to houses, everybody knows and understands the concept of cross-functionality between different functionalities and common resources and realizes the bathroom functionality has a probability of polluting the 'working environment' of the kitchen functionality.

Everybody realizes this could result in an unexpected and unwanted outcome for many people soon after eating a meal processed in the kitchen.

Everybody knows, understands and communicates there could be an emergency out-of-flow condition involving the shared resources that could last 24 hours, maybe more.

Worse yet, everybody knows and does not even need to communicate there is risk through this period the required demand on the bathroom functionality could be more than the functionality has the capacity to handle.

From the moment everyone first 'sees' the toilet located next to the food preparation and processing area, everybody 'knows and understands' without communication that an 'operational loss-of-use' would only compound the severity of the entire 'kitchen/bathroom-situation' which could be catastrophic to the operations of the entire house.

In terms of what this story tells us about the practice of architecture and what architects do, is a house is a structure filled with technology, but an architect architects the house, not to be a 'thing' to 'house' technology, but rather architects a house to meet the needs of being a home.

A house is just a house no matter what it has inside it, but a home is always a working environment with people going about in activities, a living system filled with people and interactions with technology, a socio-technical system, an enterprise.

It's just an easier way 'not-to-see' it because we know and understand without much thinking about it, the basic and fundamental building blocks of functionality which all houses need.

In the situation of a "house" all these variations, characteristics and issues in combinations of functional building blocks are commonly understood and can be communicated with only a reasonable need for further explanation or clarification, mostly driven by exceptions to 'the rule', for example a "Tree House".

This is not the case for "Enterprise" in the specific use of "Enterprise Architecture" (EA) as evident by practitioner discussions of the practice of enterprise architecture ("the practice of EA"). EA discussions tend to be black holes of miscommunication and misunderstanding.

Enterprises & Their Architectures

Enterprises come in many variations also.

Communication of the word "enterprise" could be understood to mean just about any endeavor.

"Enterprise" could be understood to specifically mean what is in the 2-D architectural description below. Additional details of this "Enterprise" can be seen in the 3-D architectural description shown in the header of the post.

This specific enterprise is 'housed' within a "starship" and has a 5-year mission to explore strange new worlds, to seek out new life and new civilizations, and to boldly go where no man (or woman) has gone before. After the mission the "Enterprise" is intended to be transformed at that stage in the enterprise's life into a series of sequential missions, serving the needs of the owning Corporation, "USS Movies Inc.".

The Starship of the "Enterprise" itself is a technology system used to enable and assure the mission and success of the socio-technical system of systems it is an element of.

In the specific situation below, the "Enterprise" is the 'thing' in the center of the description of an operational scenario. The thing with "Enterprise" described across the top of the section of the element that looks like a "Frisbee" above the element that looks like a "jet engine". The Frisbee element is interconnected with and interdependent with the jet engine element and neither element is useful without the other. Additionally, the human resources are a critical resource of the "Enterprise", with people interconnected with and interdependent on the "Enterprise", and neither is useful without the other also. Without the starship, or with catastrophic damage to the starship, the people cannot exist, making the health and well-being of the starship an important thing to consider in the strategy, planning and decisions of the "Enterprise".

In this description the "Enterprise" is described in a 'state of servicing', taken out of its external working environment, voyaging through Outer Space, exploring the final frontiers of the universe. Activities associated with servicing the "Enterprise" include a range of sustainment initiatives ranging from replacing obsolete capabilities, to performing updates, repairs and modifications, to replenishing of critical resources.

Within the "Enterprise" are an organized and integrated group of people, process, information and technology working to provide the "Enterprise" the ability to explore the final frontiers and accomplish its 5-year mission.

?In the Frisbee-like element of the "Enterprise" is a management and control capability called the "Bridge" consisting of an organized and integrated group of people, process, information and technology. This specific capability is a management and control capability associated with controlling the resources and activities of the "Enterprise" and everyone and everything within it, including individual and over-all health and well-being. The people within this capability are responsible for controlling the resources and activities of the "Enterprise" through governance, organization, integration, compliance, assurance and management of the capabilities and the resources needed.

In the following architectural definition of an operational scenario, the "Bridge" is described in a situation-of-danger in the working environment, with starships of competitors threatening the "Enterprise's" existence, and the Captain commanding the Chief Engineer, "Scotty get us out of here!"

Scotty, the Chief Engineer, is located in one of many propulsion capabilities, specifically within the jet engine-like element of the "Enterprise" called the "Impulse Engine" in a facility known as the "Engine Room".

The "Impulse Engine" propulsion capability is an organized and integrated group of people, process, information and technology associated with providing the "Enterprise" the ability to gain the thrust needed to propel the "Enterprise" to another location in Space, with better opportunities and where it is better positioned to achieve its mission.

Within the "Engine Room" is another management and control capability consisting of an organized and integrated group of people, process, information and technology associated with managing and controlling the activities of all propulsion capabilities and everyone and everything within these propulsion capabilities.

In the following architectural definition of an operational scenario, the "Engine Room" is described in a situation-of-stress with insufficient supplies of a critical resource needed to power the engines, and the Chief Engineer responding to the Captain's command with his insight into the problem, "We don't have enough dilithium crystals, Captain!"

All this is of course according to the "Enterprise" and what it has communicated about itself to me, an observer, and how well I understand the description, along with how much I already know about the "Enterprise" and have ability to communicate what it is, where it is in its lifecycle, and where it might be in the future.

If I was working for the "Enterprise", considering the Starship was recently serviced, I'd suggest they review their material replenishment capability to determine the root cause and corrective action for the lack of the crystals when needed in an emergency situation. Knowing what I know about where the "Enterprise" has been, there is probability an error was made in the resource strategy and planning, not accounting for the extra crystals needed for powering the force field needed in the unforeseen battle the "Enterprise" had with the "Klingons", a competitor.

In this specific situation the "Enterprise" was lucky because the resources of the "Enterprise" were very capable, the human resources being skilled, knowledgeable and experienced in propulsion science and methods, and were able to develop a workaround-solution which allowed the "Enterprise" the extra propulsion capacity it needed to escape the threat, allowing the "Enterprise" to survive and see more voyages with the "Enterprise", crew and resources continuing to accomplish their mission.

When it comes to understanding and communicating the word "enterprise" and its "architecture" that is as good as the description ever gets in that amount of words and effort and something which is never achieved in an EA discussion. The practice of EA sure could use that level of understanding and communication when it comes to defining exactly what an enterprise is between practitioners and who does what and when in terms of practicing EA.

In terms of what this story tells us about the practice of EA and what enterprise architects do, is an enterprise is a structure filled with technology, and an enterprise architect architects the enterprise, not to be a 'thing' to 'house' technology, but rather architects an enterprise to meet the needs of being a working environment with people going about in activities, a living system filled with people and interactions with technology, a socio-technical system.

An easier way 'to-see' it is to know and understand the basic and fundamental building blocks of functionality which all enterprises need.

Practitioners, SMEs & Their Perspectives

Many practitioners 'think' an "enterprise" is a "business for-profit or not-for-profit, an agency or institution" and 'know' a business for-profit or not-for-profit, an agency or institution is what they use the practice on, understanding and accepting there are variations in 'endeavors' and the 'patterns' within.

Many subject matter experts (SMEs) on the 'other side' of the situation 'know' an "enterprise" is more and less than a 'business for-profit or not-for-profit, an agency or institution" and 'think' it can be an infinite variety of 'endeavors' and an infinite variety of 'patterns' within.

They are actually both correct within their own views, as each 'sees' what is of interest to them in the situation they see and filter out those things they have little or no interest in. They do this by concentrating on the things which matter the most to their specific mission and goals in practicing EA.

It is only a difference in perspective, each observer looking at the same situation-of-interest with different points-of-interest from different points-of-view. When a business architect and an IT architect look at a problem, they see different things too, and for all the things they see between them, it still does not include the things an information architect sees, nor the things a process architect, system architect or service architect see. No matter how it is looked at, the thing is the thing and needs everyone to look at it to see-the-whole thing.

This story tells us that in the practice of EA every architect looks at the same situation in a different way, each from the perspective of what functionalities serve their goals and are therefore of interest to them. When the architect on the boat cares only about the island, and the architect on the island cares only about the boat, both fail to see they are within the same problem space needing a common solution, neither appreciating their need to support accomplishing each other's goals, and 'everybody knows' lack of organization and integration between interconnected and interdependent functionalities results in an over-all functionality of less value, commonly referred to as "dysfunctionality".

Knowing, Understanding & Communicating Architecting

If an architect is architecting 1 house for 600 people to live in or architecting a 600 story building for 1 person to live in, because there is a basic and fundamental understanding of what a house and a building are, neither case is commonly understood to be a 'good' situation, from the perspective of cost, schedule and ability to meet the needs of the people and person 'living' in them. Most probably either situation will degrade health, welfare and general well-being and other desired characteristics of their existence.

It is not difficult to understand or communicate that 600 people living in a house or one person maintaining a 600 story building are probably not going to have good results nor good outcomes no matter how you look at either situation.

In these examples of the house and the building it is easy to see that the structure of the house is not aligned and balanced with the intended purpose of a house, and the building is not aligned and balanced with the intended functionality needed by a person.

Neither situation is good and both situations are easy to understand and communicate what the problems may be, what the possible solutions are, and how well each solution solves the problem, the new opportunities it could provide, and the risks of moving ahead with the project if the problems are not solved and the risks are not mitigated.

Functional Building Blocks

Houses are easy to understand and communicate compared to enterprises because the basic and fundamental building blocks of houses are well known, not because there is little variation in houses. No matter how complex the variations of building blocks get, communication and understanding is maintained. The practice of EA needs just a small portion of that level of understanding and communicating between practitioners just to get over the basic and fundamental terms before jumping into the basic and fundamental practices and principals which need use of these terms.

Since I have been working on the definitions of the basic and fundamental terms used in the practice of EA, I eventually gave Ken what he asked for, the definition of an enterprise and then used it later in the discussion to define an architecture of an enterprise.

But it took four days of comments, answering questions, correcting miscommunication and misunderstanding, and expanding views to get the audience to see a bigger, higher, wider and deeper picture of what Ken asked for. So go try to find these definitions in a month old, 800+ comment LI Group Discussion. That is why I put these definitions together here in a known place, after another connection of mine, Charles Rosenbury, asked me to repost what is now this post, instead of losing these 2 definitions in another discussion of them.

To begin,

An enterprise is a collection of people, process, information, technology and other resources capable of realizing a value-added ability to satisfy a customer-based need, in order to accomplish the goal of serving the enterprise mission and sustaining the existence of the enterprise .

The following 4 minute video provides insight into this definition:

To sum it up an enterprise is a system. Getting on with it, the architecture of an enterprise is a description of the system. Specifically,

The architecture of an enterprise ( the architecture) is a description of the capabilities of the enterprise. In practice the architecture is described through multiple architectures of common resources serving different purposes for a common mission, driving the need to effectively and systematically describe all architectures as one cohesive architectural description.

The architecture describes the form and function of interrelated structures of ‘resources’ and is used to support the functionality to conceive, organize, develop, record, govern, enable, manage, analyze, plan, execute, control, monitor, measure, improve, maintain and assure the success of the enterprise as a whole, for the purposes of satisfying the cost, schedule, ability and other needs and requirements of the customers and stakeholders, serving the enterprise mission, and sustaining the existence of the enterprise.

The architecture is used by the managers as a management tool to understand and communicate enterprise capabilities and their management in support of the execution of management responsibilities and activities.

The architecting of the architecture is the responsibility of the architect.

The architecture of the enterprise and the architectures of all elements are graphical representations and definitions of the managed capabilities of the enterprise.

The architecture is used to enable and assure knowledge, understanding and communication of the interconnections and interdependencies between the systems and system elements of the capabilities.

The architecture defines the conceptual, physical and logical form and function of the enterprise including the business, process, insight, IT, technology system and service elements which compose the enterprise and the interconnections, interfaces and relationships. The functionality of the enterprise is defined by the requirements of the enterprise that enable and assure the enterprise to function to serve the requirements of the mission in the external working environment.

The architecture is formed to satisfy the functionality requirements and any other non-functional requirements to satisfy customer, user and stakeholder needs. Enterprise requirements are allocated to the elements and the elements are formed to satisfy the element requirements.

Conclusion

There is nobody that is going to PAY to use the practice of EA to architect a lemonade stand, so why leave the definition so open that it loses the ability to paint the picture of reality in the head of the business person reading the definition? But, 'poetic license' can be used with the definition and it works for lemonade stands too, although what is the chance of EA being practiced on it? It does not hurt to be specific and it sure will help the PRACTICE. Let's cross the bridge of using the definition elsewhere when we get there. I know of nobody headed that way.

At the end of the day we need specific definition for the practice of enterprise architecture that embodies the principals and purpose for enterprise architecture. For example, that is why I have “value-added” in the definition of an enterprise. Regardless of architected or not, if the business is not intending to deliver an added-value to the customer, the enterprise will have no customers and that is not a good business model.

On my part, there was a strong intention to ensure this is not exclusionary definition and to leave as much latitude open to meet any possible need. But on the other side of that argument I would like to see some definition that is tied to the overwhelming instances of practice which help to promote common understanding and communication of the basic and fundamental building?blocks of functionality used in the practice. That way there can be productive discussions about the practice, while the practice will remain usable on anything else anybody wants to use it for. Good for a lemonade stand to a mega corporation but also good for use on architecting mountain climbing endeavors or solutions to world problems.

Think of all the practitioners and misunderstandings, all the executives wondering what the value is in EA after not having the value delivered to them, and ask yourself this question:

Is it worth being unspecific to cover an instance that may never happen?

What's Next?

To move forward with the idea of using basic and fundamental building blocks of functionality we need a view where we can see these blocks both in traditional architectural descriptions and also as they 'work' within the dynamics of change over time. In other words, the way the cross-functionalities work during the transformational span from the as-is to the to-be state.

In this article I defined an enterprise and its architecture in context to the practice of EA. I did this by describing in words, a vision of an enterprise and used a holistic and philosophical perspective.

In my next article "Outside-Inward-Inside-Outward" I begin to describe this holistic and philosophical view of an enterprise.

For more information on the architecture of an enterprise, please see "Defining Enterprise".