Search Results for: business model

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.

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.

Assets and services

by

What is a service? And what do services do? Seems like it’s time to re-explore some of the routine questions that come up almost every day in a service-oriented enterprise-architecture… not least because these questions are right at the core of the Enterprise Canvas model. And, in turn, the discipline and rigour about services that modelling […]

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…

Announcing: Third Annual Enterprise Summer School

by

Week 31 is for students and researchers as well as practitioners in the field of enterprise architecture, who want to spend a pracademic week together and share and learn more about EA. 
Dates: 30 July – 3 Aug 2012
Location: IT University of Copenhagen
REGISTER NOW
Themes:

EA as a Discipline and a […]

Gartner et al. – gettin’ there on EA

by

Nice to see that even the ‘big fish’ are finally ‘gettin’ there’ on the real scope of enterprise-architecture… A month ago we saw Open Group begin to re-frame their previous IT-centred approach to EA into a new style of ‘enterprise transformation’. (The conference was still more IT than anything else, of course, but at least […]

Link Collection — May 13, 2012

by

  • How Will You Measure Your Life? – Harvard Business Review

    “I’ve thought about that a million times since. If I had been suckered into telling Andy Grove what he should think about the microprocessor business, I’d have been killed. But instead of telling him what to think, I taught him how to think—and then he reached what I felt was the correct decision on his own.

    That experience had a profound influence on me. When people ask what I think they should do, I rarely answer their question directly. Instead, I run the question aloud through one of my models. I’ll describe how the process in the model worked its way through an industry quite different from their own. And then, more often than not, they’ll say, “OK, I get it.” And they’ll answer their own question more insightfully than I could have.”

    tags: Business hbr christensen

  • Busting CIO Myths — Interview with Jeanne Ross

    Governance: “good governance is about making everybody smarter about IT. “When setting up governance, most companies start with IT investments when they should start with implementation reviews,” says Ross. “Companies with the best governance are constantly assessing whether projects are realizing their business case.””

    Purpose: Ross. “Quarterly financial goals are destroying us. IT is about the long-term strength and agility of the business. Let somebody else worry about quarterly goals; the CIO should focus on making the company great forever.”
    That doesn’t mean IT can ignore all quarterly pressure, but CIOs should discourage investment that is driven by short-term thinking. “This is UPS’s genius,” Ross says. “They understand that they need low package-delivery cost and high reliability. They use those metrics to set goals, and they build systems to operationalize their business.” CIOs must push back, she says. “If we measure IT the way we measure the last advertising campaign, we’re in trouble.”

    tags: cio governance entarch

  • Cloud & the evolution of the enterprise architect – Cloud Computing News

    I owe a follow-up on James’ excellent article. In short, I believe we need to embrace the mindset of Product Managers, who continually evolve a solution, rather than try for all-at-once perfection. 

    “In businesses that are themselves complex, there are tremendous efficiencies to be gained by the smart application of IT. That element of the enterprise architect’s role doesn’t go away.

    What does change are the skills needed to evaluate how business applications, data sets and services are going to interact-and survive-in a complex, adaptive systems environment. If developers are the DNA of software in the cloud, the enterprise architect becomes the immune system, encouraging the growth of systems that help the business thrive, and killing those that would cost the business.

    In this sense, my friend Brenda Michelson, a consultant specializing in enterprise architecture, put it best: the role is no longer one of enterprise architect, but rather one of the enterprise product manager…”

    tags: cloud computing enterprise-architect entarch

  • Big Data, Tiny Insights | Om Malik

    “Big Data needs its unit of human computational threshold so it appeals to the billions that can benefit from it. Me? I’m waiting for Big Data to become Tiny Insights. Tangible bites of intelligence that help me make better decisions and improve outcomes. Make no mistake: Tiny Insights doesn’t mean tiny value. Tiny insights inform massive decisions for business or important decisions for individuals.” — Sameer Patel

    tags: bigdata

  • The Simplicity Thesis | Fast Company

    “Here are just a few ways to get started in achieving minimum complexity:

    Think end to end.  Simplicity relates to the entire customer experience, from how you handle pricing to customer support.
    Say no.  Kill features and services that don’t get used, and optimize the ones that do.
    Specialize.  Focus on your core competency, and outsource the rest–simplicity comes more reliably when you have less on your plate.
    Focus on details.  Simple is hard because it’s so easy to compromise; hire the best designers you can find, and always reduce clicks, messages, prompts, and alerts.
    Audit constantly.  Constantly ask yourself, can this be done any simpler? Audit your technology and application frequently.
    The next thing to understand is that simplicity is a relative, moving target. The accelerating speed of innovation ensures that you’re never the simplest solution for long.”

    tags: simplicity

  • Crush the “I’m Not Creative” Barrier – Jeff Dyer, Hal Gregersen, and Clayton M. Christensen – Harvard Business Review

    “You can actually become more creative by changing your mind-set. Anyone can innovate, if they choose to. Disruptive innovators do it by choice, not chance. Their everyday actions swap out an “I’m not creative” mind-set for an “I am creative” one. And then magical (not mystical) things unfold.

    The magic materializes as people engage unique innovation skills (what we call their innovator’s DNA) on an everyday basis. For example, by asking provocative questions, observing like anthropologists, networking with people who see the world in 180-degree opposites, and experimenting with intensity, innovators obliterate the “I’m not creative” brain barrier and, more often than not, break out from the pack.”

    tags: innovation creativity mindset christensen

Posted from Diigo. The rest of my favorite links are here.

Related posts:

  1. Link Collection — January 29, 2012
  2. Link Collection — May 6, 2012
  3. Link Collection — March 4, 2012