Application Architecture Models, Tools, and Techniques

The TOGAF ADM Phase C is delivers the Information Systems Architecture. This Phase exists to develop the application architecture and data architecture that comprise the information systems. In TOGAF, the first step is to determine the views required, and the models required.

Stakeholder Concerns will identify the views. There are seven central application architecture models.

• Application Development Model that describes the acceptable method a system will be developed
• System Model that captures the large systems your application portfolio is designed around
• Functional Model that describes all the things you need your software portfolio to perform
• Product Model that identifies the functionality used in your organization's products and services, as well as those that administer them
• Integration Model describes how information flows through your application portfolio
• Service Model breaks your application portfolio down to black boxes and allows you to ensure each Service has the agility, automation, and other attributes required
• Physical Model identifies the real applications, commercial, SaaS, or custom, in your application portfolio

Application Architecture Models

Developing an application architecture will require developing several enterprise architecture models. Each explains the enterprise's software portfolio differently. TOGAF Phase C Application Architecture is all about developing the Target Architecture through these models. Ensuring the target application architect works with the other domains to enable the best improvement for your enterprise.

Taken together, the models describe the application architecture. In the complete enterprise architecture, these models will link to other models that describe the other enterprise architecture domains.

Application Development Model

The Application Development Model describes how software will be developed. The model requires a Functional or Physical Model. The Functional Model is far better because it is a logical identification software.

There are four application development types: SaaS, enterprise suites, specialist commercial packages, and custom development. Each type has unique characteristics and implications.

• SaaS characteristics include packaged software with well defined interfaces. A third party controls the lifecycle. Customization is not available.

Best used for business activities that are administrative and indirectly support value producing activity. The tight software restrictions drive restrictions in business activity and help force adoption of standard industry practices.

• Enterprise suites characteristics include multiple overlapping functional models, with defined data model. Interfaces and functionality can be configured or customized. Customizations invariably create addition cost during the lifecycle. Lifecycle is influenced by a third party.
• Specialist commercial packages characteristics include point focus and functional optimization for the specialist activity. Typically designed around one way of approaching the business activity. Usually has a unique, well-defined data model. Interfaces and functionality can be configured. Customization might be possible. Customizations invariably create significant cost during the lifecycle. Lifecycle is heavily influenced by a third party.
• Custom development characteristics include direct alignment between your organization’s legacy organizational boundaries and activities. Invariably designed to support the existing communication model of your organization. Point focus and functional optimization for the specialist activity. Expect a poorly defined data model. Interfaces and functionality must be customized. Lifecycle management is usually ignored and carries a high ongoing cost.

Best used for business activities in the primary value chain. The flexibility allows optimization of how value is generated. Effective use requires understanding value generation today and in the future.

System Model

The system model is an abstraction of software around an activity. Think about the ‘supply chain system’ and everything that is involved in the supply chain. The design of your system model will align with how your enterprise runs.

Like the business architect’s capability model, a system model allows you to direct thinking to a system. You can look at improving a complete system, then focus the required changes on everything that comprises the system and interacts with it.

Functional Model

The Functional model breaks your software portfolio down to functionality. It identifies all the things your software needs to do. Good functional models provide broad coverage.

Like the business architect’s process model, a functional model is often a reference architecture. It is powerful when you are looking for duplication and integration. Often forms the basis of an Application Development Model, where different Functional blocks are assigned a target application development type.

Critical in application portfolio planning. Duplication and Integration drive complexity and cost into the IT Portfolio.

BIAN, FEAF, TMForum's ODF, and IndEA all provide Functional Models.

Product Model

A Product Model is a specialized version of a Functional Model that highlights the functions required for your Products or services. A good Product Model will classify what is performed in comparable terms.

A good Product Model will form the basis of a reference architecture for your products. You need to specify functions that are central to the product's value, use, and administration. A Product model will inform the Application Development Model choices. You need Custom Development, duplication, and a significantly higher ability to change when the functions are associated with your Products and Services.

Integration Model

An Integration Model identifies boundaries in your software and the method the boundary is crossed. Don’t be afraid to specify that the boundary cannot be crossed or must be crossed manually. A lot of weak application integration only delivers rigidity. Developing a useful Integration Model requires iteration with a Business Architect’s work developing an Organizational Map and Information Model. The Integration Model, Organizational Map, and Information Model inform and constrain each other.

The Integration model is critical in enabling enterprise agility, managing the application portfolio, and lowering IT cost.

Service Model

A Service Model is a specialized version of a Functional Model that collapses Functionality into a black box with known interfaces. A good Service Model is invaluable in developing the Application Development Model and validating the Target in a System Model. The interfaces in your Service Model should all be well identified in your Integration Model.

A good Service Model will enable enterprise agility. Not from the development if application services, but by freeing change in one part of your enterprise from another.

Physical Model

A Physical Model is the real software portfolio. We will describe it in terms used by commercial software vendors and your application development program. You will need to associate this to the other Application Architecture Models to transition the Target into the real-world.

You use the Physical Model as a constraint on the abstract application architecture models. It also forms the basis of the Implementation and Migration Plan developed through Phase F.

Application Architecture Techniques

We use a broad set of techniques to develop and communicate our application architecture.

• UML is ubiquitous in good model-driven-development. When you are working in Architecture to support Solution Development, a Functional Model and Integration model should be developed following UML practices.
• 4+1 Views are very useful in identifying the implication of the Target for different communities. Developing 4+1 models helps ensure you are considering all relevant changes.
• DODAF's Information Needlines pull out all required information flows. It doesn't matter if the node is a person, an organization, or a system. Information will flow in and out. The fastest way to eliminate automation is to put manual steps in the middle of an information flow.

Application Architecture Models Aligned to Enterprise Architecture Purpose

The level of question you are answering with your business architecture will drive use of different business architecture models. For example, Architecture to support Portfolio often won't develop a Value Chain model. Instead, a Value Chain will usually be superior architecture and constrain your freedom.

	Architecture to Support Strategy	Architecture to Support Portfolio	Architecture to Support Project	Architecture to Support Solution Delivery
Application Development Model	Key Deliverable	Key Deliverable	Superior Architecture	Superior Architecture
System Model	Regular Deliverable	Key Deliverable	Superior Architecture	Superior Architecture
Functional Model	Regular Deliverable	Key Deliverable	Key Deliverable & Superior Architecture	Key Deliverable & Superior Architecture
Product Model	Occasional Deliverable Appropriate level of detail often diminishes value	Regular Deliverable Appropriate level of detail often diminishes value	Key Deliverable	Key Deliverable
Integration Model	Occasional Deliverable Appropriate level of detail often diminishes value	Regular Deliverable Appropriate level of detail often diminishes value	Key Deliverable	Key Deliverable & Superior Architecture
Service Model	Occasional Deliverable Appropriate level of detail often diminishes value	Regular Deliverable	Key Deliverable & Superior Architecture	Key Deliverable & Superior Architecture

Business Architecture Models Influence on Application Architecture Models

	Business Model	Operating Model	Value Chain	Capability Model	Process Model	Functional Model	Information Model	Organization Model
Application Development Model	Major input Requires a System or Functional Model	Major input Requires a System or Functional Model	Major input Requires a System or Functional Model	Major input Requires a System or Functional Model	Major input Requires a System or Functional Model	Major input Requires a System or Functional Model	Limited Input	Limited Input
System Model	Limited Input	Limited Input	Limited Input	Limited Input	Limited Input	Major Input	Limited Input	Major Input
Product Model	Major Input	Major Input	Major Input	Limited Input	Limited Input	Limited Input	Limited Input
Integration Model	Very Limited Input	Major Input on core design Requires a System or Functional Model	Major Input on core design Requires a System or Functional Model	Best Input A direct link is very difficult to see. It is worth doing the work.	Major Input on core design Requires a System or Functional Model	Limited Input Use only if other models are not available	Major Input on core design Requires a System or Functional Model	Major Input on core design Requires a System or Functional Model
Service Model	Limited Input The linkages are important, but a direct link is very difficult to see	Limited Input The linkages are important, but a direct link is very difficult to see	Limited Input The linkages are important, but a direct link is very difficult to see	Best Input A direct link is very difficult to see. It is worth doing the work.	Used as a completeness test	Major Input A direct link is very difficult to see. It is worth doing the work.	Major Input

Application Architecture Models for Enterprise Architecture Use Cases

All enterprise architecture use cases are about change. They all look at types of change, and how an enterprise architect helps decision makers chart a path forward.

I consider the enterprise architecture use cases as the type of change, purpose of the enterprise architecture team, or questions commonly asked.

In every enterprise architecture use case, we are performing the same function. We assist stakeholder make better decisions and lead successful change initiatives. All that changes is the question.

	Strategic Change	Incremental Change	Improve Cost	Improve Quality	Improve Enterprise Agility	Mitigating Technology Risk	IT Modernization	Digital Transformation	Application Portfolio Rationalization	Acquisition Integration
Application Development Model		Key constraints	Key guidelines		Critical constraints	Critical constraints	Critical gaps and constraints	Critical gaps and constraints	Critical gaps and constraints	Critical gaps and constraints
System Model	Very useful Critical gaps and constraints	Critical gaps and constraints				Critical gaps and constraints			Critical gaps and constraints	Critical gaps and constraints
Product Model	Critical gaps and constraints					Critical gaps and constraints		Critical gaps and constraints	Critical gaps and constraints	Critical gaps and constraints
Integration Model	Informing constraints	Critical gaps and constraints	Critical gaps and constraints	Critical gaps and constraints	Critical gaps and constraints	Critical gaps and constraints		Critical gaps and constraints	Critical gaps and constraints	Critical gaps and constraints
Service Model	Very useful for gaps and constraints	Very useful for gaps and constraints			Very useful for gaps and constraints		Very useful for gaps and constraints	Very useful for gaps and constraints	Very useful for gaps and constraints	Very useful for gaps and constraints

Applying Enterprise Architecture Principles to Application Architecture

We have identified 7 Architecture Principles every enterprise architect should know. The following table identified the implications of these Architecture Principles to the Application Architecture. When performing enterprise architecture governance, you need to test your Application Architecture to ensure that it is conforming to superior architecture. Here, is it conforming to the enterprise architecture principles?

	Application Architecture Implication
Don’t Mess With Success	If the program is not differentiation or transformation, look to eliminate change. Look to avoid all change to process or system that is not explicitly cost & outcome justified.
Focus On Excellence	Align with the Operating Model the Capability Model. Leverage Application Development Model to focus spend on differentiation. Leverage Product Model to focus on the delivery of Product & Service.
Why Not One?	Leverage Application Development Model & Product Model to identify areas where duplication is prohibited.
Data is an Asset	Ensure control of the data model is not surrendered in ways that diminish the value of data asset.
Systems Work Where We Work	Work location and work style drive interface and application model.
Painless User Experience	Efficiency programs focus on existing business process. Differentiation & transformation programs require change to user interface & engagement as experience with new process is developed.
Self Service	Application administrative activities & deployment are high cost when they are not self-service Weak UX is high cost..

How does TOGAF Phase C align with Agile Development?

The Application Architecture will provide multiple constraints and guidance for agile development. The fundamental guidance comes from the Application Development Model. It identifies where you do not want agile development.

Enterprise Architecture and Agile Development will intersect on four areas. The enterprise architecture will:

1. define the agile approach
2. guide the backlog in sprint
3. constrain choices inside the sprints
4. solve for cross product dependency

We always focus agile development on novel differentiating activity and ruthlessly follow established best practice elsewhere. Best practice comes from established commercial software. Make sure you align your application architecture to your business architecture and focus on how you acquire systems.

How does TOGAF Phase C enable with Enterprise Agility?

Enterprise agility has nothing to do with how you write software. Enterprise agility is about your enterprise's ability to react to unexpected threats and opportunities. If you need to write code, your ability to respond to a threat or opportunity is at risk.

An application architect will focus on the fifth aspect of the enterprise agility model - Flexibility. We use the same Agility attribute and scores in the Capability Assessment Guide to identify the information systems that must be capable of rapid change. Then we architect to enable change.

Enterprise Agility Model

1. Alertness – Can you detect opportunities and threats?
2. Accessibility – Can you access relevant information in time to respond?
3. Decisiveness – Can you decide using the available information?
4. Swiftness – Can you implement your decisions in the time available?
5. Flexibility – What are you doing to reduce the barriers to action?