The Architectural Canvas

Gartner has created an excellent view of Enterprise Architecture. This view (shown above) describes how the Architecture can fall into four main quadrants (Gartner is famous for its “Magic Quadrants” !). These quadrants are described by their relationship to being Tactical vs Strategic, and Local vs Enterprise., which are represented along the X and Y axes:

• Enterprise - this is an architecture that spans the entire organization, regardless of department. It should envelop the Strategies and Capabilities that the Enterprise wishes to achieve. 
• Local - describes an architecture that is more subjective, perhaps being an architecture for defining the individual systems that the IT Department uses.
• Strategic - these architectures are designed to line up with the Enterprise’s Strategies and Capabilities.
• Tactical - these are architectures which align to objectives.

The Navigate method of applying the TOGAF architectural framework follows this model fairly well. And one of its principles is to understand who the members of the Enterprise Architecture team are, and how they participate. This should include stakeholders from the Enterprise, as they typically provide the Strategies which Enterprise Architecture should be delivering upon. In the Navigate method, there is an exercise which helps understand where on this canvas the individual members lie - which helps understand their role and what they deliver.

Of course, everybody wants to be the Enterprise Architect. But if we examine what the members do, we can derive how they fit. In terms of the Canvas, the four quadrants are first bisected by a line which defines Vanguard Architecture vs Foundational Architecture.

• Vanguard Architecture - this is the innovative, forward-looking architecture. It commonly looks for new ways to achieve the Strategy of the Enterprise. It will examine new technologies and methodologies. In Gartner’s view, this is the Architecture that considers the Capabilities of not only the Enterprise, but those of its Customers, Suppliers and Competitors. This is referred to as “Outside-In Architecture”.
• Foundational Architecture - this tends to be thought of as more of a Traditional way of looking at ONLY the Enterprise and its capabilities, often re-defining Services to be more efficient. This is referred to as “Inside-Out Architecture”.

The two dashed red lines describe the traditional Roles within the Architecture realm. Many Enterprises are moving away from a model where there is a discrete group of Architects that participate in the Architecture field, and move towards a more Federated or Social model. This implies that the Architecture group is such more broadly defined, just as their roles need to be.

• Enterprise Architects - look at the Enterprise holistically, helping the Enterprise understand how to change to suit an ever-changing landscape. They build out the Conceptual Architecture required for transformative change.
• Principal Architects - typically are Solution Architects, but tend to look less at the entire Enterprise, and more at individual Lines of Business. They look after an individual set of Capabilities. 
• Solution Architects - tend to be Project-focused, with a solid understanding of the systems which provide the Services of the Enterprise. They build out the Logical Architecture, defining how systems will deliver the Services, and their requisite Functional Requirements.
• Technical Architects - also Project-focused, they develop the Physical Architecture by interpreting the Logical Architecture and applying the Non-Functional Requirements required to satisfy the Solution.

A solid Federated Architecture will have members that fall across all of the quadrants, delivering highly valuable architecture that delivers the Business Outcomes that are defined in the Strategies. This will in turn provide a high degree of traceability from the Stories and Activities defined in the CLIP Framework all the way back to the Business Outcomes.

CLIP Mapping

In this blog entry, we will try to get a better handle on some of the relationships the CLIP Framework has to the actual business itself. Without having tangible Business Outcomes, the framework has no value to the business.

C is Conceptual

Down the middle of the diagram, we see the hierarchy of the framework. As we have seen in previous entries, the top of the hierarchy is the Strategy. The term strategy is defined as a plan of action or policy to achieve one or more goals under conditions of uncertainty. These are the Outcomes the framework seeks to achieve. The next line is the Capability, which for our purposes is synonymous to the Objective - note that there could be multiple Objectives ! In business terms, the Capability aligns to the things the business does to offer its products or services. The Strategy & Capabilities are the foundation of the Conceptual Architecture. If the Strategy is to provide an Omni-Channel means of selling to customers, the Capabilities are to deliver the shopping experience in multiple ways - through both store-front operations and through an eCommerce web-site. The Conceptual architecture provides a means of delivering those Capabilities to meet the overall Strategy.

L I for Logical and Informational

The business will develop Processes for repeatability. Multiple Processes bundled together become the Capability. For example, an eCommerce web-site is a Capability - it is a means of selling products or services to a customer. There might be more than one Capability, such as brick and mortar stores as well as the eCommerce web-site. But the Capability must encompass a number of Processes, like being able to browse the selection, add them to a virtual shopping cart, calculate the price, taxes and a running total. All of these Processes sum up to a Capability. And, just as every process sums up to a capability, a number of Services sum up to a process. Discrete services are often reusable. The process of building a virtual shopping cart in an eCommerce web-site is exactly the same as checking out a client at a cash register in a store. Informational Architecture is about transformation. A number of services need to work together to form a process. Those services are all dependent on information (raw data which has been processed into a usable format) which may come from disparate sources. And each of these sources will have their own way of storing, manipulating and serving that information, so often there is some form of translation (transformative process) which makes the information usable to the services. When building out the systems to support the Capabilities, the Processes & Services provide the Functional Requirements. These describe how the system and the associate interact to perform the Processes.

P for Physical

The Activities and Stories are important to the Framework, as they describe the manual steps required to perform a set of tasks. For example, a store associate might receive an item from a client. They find and scan the barcode on the label, check that the description matches the garment, the system adds the garment to a virtual shopping cart and calculates price, discount and taxes, which are displayed on the screen for the customer and the associate to see. They then make decisions about which activity is next, depending on the form of payment a client wishes to use. So the Stories describe how the associate interacts with both the client and the system to perform all of the activities. The Activities drive out the Non-Functional Requirements. These are usually about the time it takes to perform a transaction, or how many transactions a system can handle in a given time-period.