Aggregated enterprise architecture wisdom
After spending three months alone in a windowless-but-air-conditioned office, the business analyst emerged with a two-hundred-page document of business, functional, and non-functional requirements. A short time later, her contract concluded, the document was discarded because it was useless — it was useless and it was very expensive. As part of understanding how to balance precision […]
I have been spending a lot of time thinking about Application Architecture in the context of EA. More specifically, as an Enterprise Architect, what do I need to consider when looking at/defining/designing the Application Architecture Domain?
There are several definitions of Application Architecture. TOGAF says “The objective here [in Application Architecture] is to define the major kinds of application system necessary to process the data and support the business”. FEA says the Application Architecture “Defines the applications needed to manage the data and support the business functions”.
I agree with these definitions. They reflect what the Application Architecture domain does. However, they need to be decomposed to be practical.
I find it useful to define a set of views into the Application Architecture domain. These views reflect what an EA needs to consider when working with/in the Applications Architecture domain. These viewpoints are, at a high level:
Capability View: This view reflects how applications alignment with business capabilities. It is a super set of the following views when viewed in aggregate. By looking at the Application Architecture domain in terms of the business capabilities it supports, you get a good perspective on how those applications are directly supporting the business.
Technology View: The technology view reflects the underlying technology that makes up the applications. Based on the number of rationalization activities I have seen (more specifically application rationalization), the phrase “complexity equals cost” drives the importance of the technology view, especially when attempting to reduce that complexity through standardization type activities. Some of the technology components to be considered are:
Organization View: Organizations are comprised of people and those people use applications to do their jobs. Trying to define the application architecture domain without taking the organization that will use/fund/change it into consideration is like trying to design a car without thinking about who will drive it (i.e. you may end up building a formula 1 car for a family of 5 that is really looking for a minivan). This view reflects the people aspect of the application. It includes:
Information View: Whether or not you subscribe to the view that “information drives the enterprise”, it is a fact that information is critical. The management, creation, and organization of that information are primary functions of enterprise applications. This view reflects how the applications are tied to information (or at a higher level – how the Application Architecture domain relates to the Information Architecture domain). It includes:
Application Service View: Organizations today are striving to be more agile. As an EA, I need to provide an architecture that supports this agility. One of the primary ways to achieve the required agility in the application architecture domain is through the use of ‘services’ (think SOA, web services, etc.). Whether it is through building applications from the ground up utilizing services, service enabling an existing application, or buying applications that are already ‘service enabled’, compartmentalizing application functions for re-use helps enable flexibility in the use of those applications in support of the required business agility. The applications service view consists of:
Delivery Model View: It is hard to talk about EA today without hearing the terms ‘cloud’ or shared services. Organizations are looking at the ways their applications are delivered for several reasons, to reduce cost (both CAPEX and OPEX), to improve agility (time to market as an example), etc. From an EA perspective, where/how an application is deployed has impacts on the overall enterprise architecture. From integration concerns to SLA requirements to security and compliance issues, the Enterprise Architect needs to factor in how applications are delivered when designing the Enterprise Architecture. This view reflects how applications are delivered to end-users. The delivery model view consists of different types of delivery mechanisms/deployment options for applications:
While by no means comprehensive, I find that applying these views to the application domain gives a good understanding of what an EA needs to consider when effecting changes to the Application Architecture domain.
Finally, the application architecture domain is one of several architecture domains that an EA must consider when developing an overall Enterprise Architecture. The Oracle Enterprise Architecture Framework defines four Primary domains: Business Architecture, Application Architecture, Information Architecture, and Technology Architecture.
Each domain links to the others either directly or indirectly at some point. Oracle links them at a high level as follows:
Business Capabilities and/or Business Processes (Business Architecture), links to the Applications that enable the capability/process (Applications Architecture – COTS, Custom), links to the Information Assets managed/maintained by the Applications (Information Architecture), links to the technology infrastructure upon which all this runs (Technology Architecture – integration, security, BI/DW, DB infrastructure, deployment model).
There are however, times when the EA needs to narrow focus to a particular domain for some period of time. These views help me to do just that.
I recently had a discussion around who should own an organization’s Enterprise Architecture. It was spawned by an article titled “Busting CIO Myths” in CIO magazine1 where the author interviewed Jeanne Ross, director of MIT’s Center for Information Systems Research and co-author of books on enterprise architecture, governance and IT value.
In the article Jeanne states that companies need to acknowledge that “architecture says everything about how the company is going to function, operate, and grow; the only person who can own that is the CEO”. “If the CEO doesn’t accept that role, there really can be no architecture.”
The first question that came up when talking about ownership was whether you are talking about a person, role, or organization (there are pros and cons to each, but in general, I like to assign accountability to as few people as possible). After much thought and discussion, I came to the conclusion that we were answering the wrong question. Instead of talking about ownership we were talking about responsibility and accountability, and the answer varies depending on the particular role of the organization’s Enterprise Architecture and the activities of the enterprise architect(s).
Instead of looking at just who owns the architecture, think about what the person/role/organization should do. This is one possible scenario (thanks to Bob Covington):
While there are many more roles and responsibilities than listed here, it starts to provide a clearer understanding of ‘ownership’. Now back to Jeanne’s statement that the CEO should own the architecture. If you agree with the statement about what the architecture is (and I do agree), then ultimately the CEO does need to own it.
However, what we ended up with was not really ownership, but more statements around roles and responsibilities tied to aspects of the enterprise architecture. You can debate the semantics of ownership vs. responsibility and accountability, but in the end the important thing is to come to a clearer understanding that is easily communicated (and hopefully measured) around the question “Who owns the Enterprise Architecture”.
The next logical step . . . create a RACI matrix that details the findings . . . but that is a step that each organization needs to do on their own as it will vary based on current EA maturity, company culture, and a variety of other factors.
Who ‘owns’ the Enterprise Architecture in your organization?
1 CIO Magazine Article (Busting CIO Myths): http://www.cio.com/article/704943/Busting_CIO_Myths
Normal
0
false
false
false
EN-US
X-NONE
X-NONE
MicrosoftInternetExplorer4
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:””;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin-top:0in;
mso-para-margin-right:0in;
mso-para-margin-bottom:10.0pt;
mso-para-margin-left:0in;
line-height:115%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Calibri”,”sans-serif”;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:”Times New Roman”;
mso-bidi-theme-font:minor-bidi;}
It is interesting to watch the debates online between the different schools of thought of Enterprise Architecture. The discussion was started by James Lapalme, who published a paper on “three schools of thought” which is in pre-print for the IEEE…
How: Some Comments on Creating and Evolving the Conceptual Architecture
During early system conceptualization, we start to envision the form or shape of the system, its boundaries and interactions, its primary elements and their interactions. The sketchy shapes of these elements, expressed mainly in terms of their responsibilities, analogies, and drawing on patterns and experience, take […]
Why: Motivation for the Conceptual Architecture View
Conceptual Architecture is a key medium for describing the “big picture” and essential design ideas of our system, helping others to more rapidly comprehend a complex system, how it is composed and its critical mechanisms or interworking to achieve some key internal system capability essential to sustaining itself. The […]
What is Conceptual Architecture?
“Conceptual Architecture” is the conceptual view(s) of the architecture of a system. It describes at a broad brushstrokes conceptual level the significant design ideas of the system. In particular, this view includes diagrams and text which identify, explicate, rationalize and contextualize the key structures and mechanisms of the system, and the relationships […]
By Leonard Fehskens, The Open Group It being the time of year for commencement speeches, Patty Donovan asked if I could offer some advice to graduates entering the Enterprise Architecture profession. She specifically asked what three things I wished I …
“TCP/IP and Ethernet will not be accepted as a valid network implementation as SNA and Token Ring are our preferred standards.” – circa 1993 by nameless corporate Information Systems expert.
I was shocked when I had heard this, and images …
“TCP/IP and Ethernet will not be accepted as a valid network implementation as SNA and Token Ring are our preferred standards.” – circa 1993 by nameless corporate Information Systems expert.
I was shocked when I had heard this, and images …
“TCP/IP and Ethernet will not be accepted as a valid network implementation as SNA and Token Ring are our preferred standards.” – circa 1993 by nameless corporate Information Systems expert. I was shocked when I had heard this, and images of ostriches with their heads in the sand immediately came into mind. I was new…
One very powerful metaphor that has reverberated throughout the technical community, in the past few years, was the Agile Manifesto. Created by a group of folks who wanted to communicate the principles that drove their thinking, the Agile Manifesto has been a very useful tool for deciding if a particular practice is being done well. I think it may be time to build one for the Business Architecture space.
That said, I am by myself, sitting in my living room. I am in no position to speak for the community of business architects. So, this submission is a suggestion for content that could be useful when the conversation begins. It is my personal opinion about the principles of business architecture. I would hope to bring this material to a group of other BA practitioners, as my contribution, to develop a full consensus on business architecture manifesto.
First off, in order to develop principles for business architecture, we need to describe the problem that we are trying to solve.
Business architecture is a relatively new field that addresses an old problem. Most business people recognize the underlying truth: the structure and practices of your organization directly impacts your ability to deliver the intended value. Whether we are talking about a military service, a civilian government agency, a non-profit organization, or a for-profit business, the structures and processes that a leader chooses to employ will impact the results that the organization will produce. That includes both intended and unintended results. So the basic problem is this: how do we deliver on our mission while maintaining our values?
Business architecture gets to deal with a slice of that problem. As people, we need to organize around a common shared mission. We need to know what we want, and we need to go get it. Humans can be pretty haphazard. Business architecture does not address every issue. Business architecture attempts to answer this question: what is the optimal way to organize? Business architecture typically does NOT answer questions around the integration of corporate controls, or supporting activities like how to find staff to fill new roles. Business architecture is focused on the narrow slice of “how to organize.”
So why do we need business architecture to solve this problem? There are literally hundreds of good, well researched, books that offer useful insight for solving this problem. Why use a business architecture approach? Because BA brings a novel approach, one based on the rigorous application of conceptual traceability, process improvement, information science, and mathematics. While most of the business analysis methods prior to business architecture were founded, fundamentally, in social science, mechanical engineering, and even education, business architecture focuses on the newer sciences that have emerged in the computerized age.
Business architecture’s unique value proposition is to focus on answering the questions of business structural and organizational effectiveness in a way that is rigorous, quick, clear, consumable, and value-focused.
We are uncovering better ways of developing business insight by doing it and helping others do it. Through this work, we have come to value:
That is, while there is value in the items on the right, we value the items on the left more.
To break that down:
I’m always looking for insight and feedback from the community, so please feel free to add your comments.
Please note: if your comment is long, the software will sometimes have trouble. Write it in notepad or Word first, and then cut and paste into the comment edit window. Don’t be afraid to send it more than once. I will delete duplicates. If all else fails, e-mail your comment to me and I’ll put it in.