#eavoices

The Application Architecture Domain

by

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:

  • Software: The application itself as well as the software the application relies on to function (web servers, application servers).
  • Infrastructure: The underlying hardware and network components required by the application and supporting application software.
  • Development: How the application is created and maintained. This encompasses development components that are part of the application itself (i.e. customizable functions), as well as bolt on development through web services, API’s, etc. The maintenance process itself also falls under this view.
  • Integration: The interfaces that the application provides for integration as well as the integrations to other applications and data sources the application requires to function.
  • Type: Reflects the kind of application (mash-up, 3 tiered, etc). (Note: functional type [CRM, HCM, etc.] are reflected under the capability view).

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:

  • Ownership: Who ‘owns’ the application? This will usually reflect primary funding and utilization but not always.
  • Funding: Who funds both the acquisition/creation as well as the on-going maintenance (funding to create/change/operate)?
  • Change: Who can/does request changes to the application and what process to the follow?
  • Utilization: Who uses the application, how often do they use it, and how do they use it?
  • Support: Which organization is responsible for the on-going support of the application?

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:

  • Access: The application is the mechanism by which end users access information. This could be through a primary application (i.e. CRM application), or through an information access type application (a BI application as an example).
  • Creation: Applications create data in order to provide information to end-users. (I.e. an application creates an order to be used by an end-user as part of the fulfillment process).
  • Consumption: Describes the data required by applications to function (i.e. a product id is required by a purchasing application to create an order.

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:

  • Services: Here, I refer to the generic definition of a service “a set of related software functionalities that can be reused for different purposes, together with the policies that should control its usage”.
  • Functions: The activities within an application that are not available / applicable for re-use. This view is helpful when identifying duplication functions between applications that are not service enabled.

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:

  • Traditional: Reflects non-cloud type delivery options. The most prevalent consists of an application running on dedicated hardware (usually specific to an environment) for a single consumer.
  • Private Cloud: The application runs on infrastructure provisioned for exclusive use by a single organization comprising multiple consumers.
  • Public Cloud: The application runs on infrastructure provisioned for open use by the general public.
  • Hybrid: The application is deployed on two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability.

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.

Oracle Enterprise Architecture Framework

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.

Who should ‘own’ the Enterprise Architecture?

by

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):

  • The CEO should own the Enterprise Strategy which guides the business architecture.
  • The Business units should own the business processes and information which guide the business, application and information architectures.
  • The CIO should own the technology, IT Governance and the management of the application and information architectures/implementations.
  • The EA Governance Team owns the EA process.  If EA is done well, the governance team consists of both IT and the business.

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

Measure What Really Matters

by

I ran across a very interesting op-ed by Tim Jackson on productivity today in the New York Times. The gist of his well-articulated argument is that due to our relentless drive for increased output, certain professions and their attendant tasks…

EA Heuristic #5: Address the concern of “you are echoing back what I told you”

by

(this article is part of the series “12 Heuristics for Enterprise Architecting“)

Stop parroting me! (photo credit: Ferran Pestaña) 

In some ways, the “as-is” phase of enterprise architecting exercises do not generate new content. It brings together observations from different parts of the organization and synthesizes them. Though the synthesis often produce “fresh” insights, these insights might seem obvious to the organization in retrospect, as they are often associated with pains that the organization has been suffering under. In our EA exercise, we received feedback on our “as-is” analysis that ranged from being “spot on” to “echoing back what I told you”, and that seem confusing until we sat down and analyzed the issue.

Learning from this experience, we could have explained to the organization why the EA team was not simply echoing back to them using the earlier mentioned logic. What we did do was to explain to them the EA methodology, and how we relied on it to systematically analyze the organization.

EA Heuristic #4: Collect and analyze data with reusability in mind

by

Metal Bottle Cap Flowers (credit: urban woods walker)
(this article is part of the series “12 Heuristics for Enterprise Architecting“)
EA exercises involve collecting a lot of data and distilling insights from them.  It seems wasteful if the fruits of these efforts are used just once and then thrown away.  Instead, when collecting data and doing analysis on them, it is useful to think about how the data and analysis can be re-used.

Specifically, as discussed in Heuristics #2: Guess, Validate, Iterate: Time-bound architectural efforts, the insights are likely to contain some inaccuracies, so expect gradual refinement of the data and analysis.  To do that, how the analysis is derived from the data should be clear.  In addition, involve as much as possible the people who are going to update it in the future.  The more familiar they are with the collected data and analysis, the more likely they will reuse it in the future.

During our EA exercise, we created a chart showing the key products offered by the organization, along with each product’s importance and satisfaction level.  We created a first draft of the chart, then we explained to the organization how we did it, and then they refined it.  We hope that they will reuse this chart, and we are more confident of it since they have already updated it once.  In addition, when we created the summary of our key findings, we tried as much as we can to resist the temptation of listing down gut feels and focus on findings that are backed up by data.