Building the Business Value Chain…

Agile EA & Resource Management

In the previous post about IT Governance,  the remaining topic to discuss is Resource Management. After Business Alignment, Value Delivery, Risk Management and Performance Measurement, this is the remaining element in IT Governance.

IT Governance

The purpose, from an IT Governance perspective, of Resource Management is to provide high-level direction for the sourcing and use of human capital. In order to successfully implement the various services required for the optimization or provisioning of business capabilities, specific skill-sets may need to be onboarded to the organization. These skill-sets may be required long-term, wherein the Human Resources team may choose to hire or train resources. Or these skill-sets may be required only in the short-term, opening up the opportunity to onboard contract resources.

As with all areas of IT Governance, KPIs and metrics for success would need to be defined and negotiated to insure the ongoing success of the optimized or new capability. As we saw, the life-cycle for the business covers inception to sunset activities, and includes the measurement of both tangible and intangible benefits. Further, these KPIs should cross the boundary between the business and IT to be complete and holistic.

By performing Resource Management activities, one of the key goals for overall Architecture Governance is satisfied. This results in a better understanding of the cost-effectiveness and value for money of the services and capability they support.


Agile EA and Risk Management

Gartner  defines Enterprise Architecture as:

“a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions.” ~

Effectively, the Practice of EA is about managing change, be it from internal or external pressures. And with change comes Risk.

As we described in a previous post, IT Governance is an ongoing practice that requires attention. And one of the biggest components requiring attention is Risk Management. Risk is defined as:

An uncertain event that, if it occurs, has a positive or negative effect on one or more project objectives. ~ PM Book of Knowledge, PMI

TOGAF-admAs we know from the TOGAF ADM (the “lollypop” on the left), sections E,F & G refer to the actual projects which represent the Implementation Phase of Enterprise Architecture.

While the activity of Managing Projects isn’t the responsibility of the Agile EA, they will participate in the ongoing Risk Assessment process that will help Projects be successful. For example, before the Project even exists, the Agile EA is considering Risk:

  • What would be the outcome if we DIDN’T do the Project ?
  • What would be the outcome if we did ?

Risks don’t have to be a negative thing, to be avoided at all costs. Risk can create positive outcomes as well, and therefore should be encouraged to occur, if possible. One good method of examining Risk wold be to perform a SWOT Analysis. Like the canvas depicts, it examines:



  • Strengths
  • Weaknesses
  • Opportunities
  • Threats


With the final outcome being some form of Risk Mitigation Plan.



Of course there are many ways to identify and plan for Risk, the SWOT analysis merely illustrates one approach. As we also saw in the previous post , Risk Management is also tied to Value Delivery. We’ll explore that more in a later post, but suffice it to say, one of the prime measurements of Value Delivery is Stakeholder Satisfaction, which measures how well a stakeholder understands what is happening in the execution of the projects that implement the Architectural Vision.



Agile EA and Value Delivery

As we saw in a previous post Value Delivery is one of the five key tenets of IT Governance. In fact, there is an entire Value Governance stream of effort that the Agile EA needs to pay attention to in order to be successful.


Value Delivery, and the Governance thereof, is described in seven guiding principles:

  1. IT Investments should be managed as portfolios This allows a holistic view of all of the interactions of projects and initiatives. This helps optimize their Value Delivery.
  2. IT Investments should include the full scope of activities And not just those that are IT related, but also those of the Business – like processes and resources.
  3. IT Investments need to be managed through their entire life-cycle From inception to sunset activities, value needs to be regularly checked & validated to see if they still deliver the same value to the business.
  4. IT Investments fall into different categories Thus, they cannot all be treated the same, as they may have tangible (financial) or intangible (reputation) benefits.
  5. Value Delivery Practices will define & monitor key KPIs & metrics It is important to understand if the practices are delivering continuous value, rather than one-time value.
  6. Value Delivery Practices will engage all key stakeholders Both the IT stakeholders and the Business stakeholders need to be actively engaged to insure success of the practice.
  7. IT Investments need to have their KPIs continually monitored for success Its not enough to measure the KPIs. They need to be re-evaluated & if there are changes, corrective action may be in order.

In essence Value Governance works to insure that IT Investments have their benefits optimized from throughout the life-cycle of the business.

Agile EA – Mapping Capabilities to Infrastructure

As Agile EAs, we are required to understand both the Business Landscape and the IT Landscape. Generally, the business landscape is described in a Business Capability Map, or BCM. This provides a very Strategic view of the Business in terms of the capabilities it has. As we saw in a previous post on Governance, the BCM might also include information about the Maturity of those capabilities.

Capabilities Mapping

These mapping exercises between the Capability Map and the Application and Infrastructure Landscapes provide the building blocks for Agile EA. As the business grows and adapts to change, the Application Landscape will change, which could in turn force the Infrastructure Landscape to change. Equally, changing the Infrastructure Landscape – what if we migrated to the Cloud ? – places new restrictions on the Applications, but equally could expose new capabilities – like better mobile access.

Agile EA & IT Governance

A big topic for the Agile EA is Governance. It is defined as the set of activities an organization executes to ensure that decisions are made and accountability is enforced during the execution of it’s architecture strategy.

IT Governance

Using the above diagram, we can see that there are five (5) Strategic elements to IT Governance. They are:

  • Business Alignment: specifically, does the Enterprise Architecture align with the needs of the Business ? If not, the Enterprise Architecture will not be accepted by the Business Stakeholders, reducing (or even eliminating) the value perception of the Agile EA.
  • Value Delivery: the Enterprise Architecture needs to consistently deliver incremental value to the Business. This value is measured multiple ways, but in its simplest form it is stakeholder satisfaction.
  • Resource Management: the Business needs to see that it’s resources (People, Equipment, etc) are being used in a prudent manner. For example, having people with the correct skill-sets to perform specific tasks is key to the achievement of new Business capabilities.
  • Performance Measurement: as the name implies, if you can’t measure it, you can’t manage it ! Thus it is logical that the performance of EA-led activities must have success criteria and metrics to measure the success of those activities.
  • Risk Management: this is a huge area for the Agile EA to consider. Since Risk can be both positive or negative, it is a process which is ongoing. But the identification of, and planning for, Risk is a key activity that needs constant care and attention.

From those Strategic elements of IT Governance, we can then begin to drill into some Tactical activities. There are two important activities in the diagram, although they are not the ONLY tactical activities the Agile EA should look at.


Business Capability Maturity (BCM) Assessment: usually built out into a model called the Business Capability Map, the maturity levels describe how well-defined the policies & procedures are. The CMMI model (shown above) describes the levels that are applied to each Business Capability.

IT Capability Assessment: by following a similar assessment as the BCM Assessment, the IT services can be measured and be ranked for required improvements, if required.

Practical TOGAF – BAIT

I received a call from a colleague, explaining that one of his clients was looking for an Agile EA to help them define a Roadmap for Database Replication. I thought “What a curious thing !”. Of course, my colleague had only heard of the opportunity second-hand, and as such was short on details. But it gives us an excellent opportunity to apply what we know so far of the TOGAF Architecture Development Model.


The first thing I recognized is that we don’t have enough information yet. If we follow the basic tenets of Practical TOGAF, and in order to develop an understanding of what the Target State might look like, we need to examine the BAIT components. In the Mind Map above, we see that BAIT stands for Business, Application, Information and Technology. Assuming the client has followed an Architectural Framework (such as TOGAF), we can infer that they have followed the BAIT path.


As we see in the model to the left, the Business Processes or Activities are handled by the Application. Riding on its own technology, say a Point of Sale device, the Application is the interface between the User and the Information. In turn, the application rides on top of specific technologies, perhaps a JAVA-based web application, which uses the SQL language to read data from the Information Store (aka database). Finally, the Information Store requires a Relational Database to structure the information held within.


My favourite line is “What business problem are we trying to solve ?”. In this case, is the need for Database Replication to support an existing capability or a new one ? Equally, is this Technical Requirement a Reaction to a problem – perhaps the client already has a Database Replication Technology, and they think it is too expensive? Or perhaps the client wants to be Proactive, offering a new Capability or Service to the Business ? What Processes or Activities are being affected ? So many questions !


The ADM tends to lump the Application Architecture and the Information Architecture together. By using a BAIT view of the Architecture, the Agile EA recognizes that the Application is the Business’s interface to their Information. The Application provides a means for viewing and performing CRUD (Create, Read, Update & Delete) operations on the Information. So is the client looking to implement some form of High Availability for the Database which serves their Application ? Or perhaps they are more interested in Disaster Recovery, in which case they are most concerned about the Recovery Time Objectives and Recovery Point Objectives. What is they are interested in having a subset of their database available in an off-premise Cloud configuration for a new Web Application ?


The Information contained in the database is of high value. It is very common for clients to replicate the data to a secondary database engine, to separate the Application operations (CRUD), from the compute-intense reporting operations. This might have implications around whether or not the client needs the Database Replication to be Synchronous or Asynchronous. Or perhaps the data needs to be transformed to a specific Data Model, such as the ARTS Data Model for Retail. The application may not support the ARTS Data Model, but the Reporting and Data Warehouse systems might, causing the data to be Transformed during the Replication process.


Supporting both the business application and the management of the information, it is not a direct interface for the business consumer. Instead, they will access the application, which will provide a view of the information. Both the application and the information ride on top of some form of technology stack. So when considering the client’s question, it is important to understand how the technology is used and deployed. Database Replication might be handled in the database itself, or perhaps in an Integrations layer, as part of an ETL (Extract, Transform, Load) job. Perhaps it would best suit the requirements to implement storage-level replication. And of course, there’s always third party solutions.

So in order to help this client, the Agile EA would need to spend some time understanding the Business Problem that is being solved, as well as understand the Application, Information and Technology architectures in their current state. After careful analysis, coupled with knowledge of any Architectural Principles, and Agile EA could help develop such a roadmap for their client.

Practical TOGAF – Opportunities and Solutions

Double-EffectivenessIn the previous post, we examined the steps required to determine the Enterprise‘s current state, to devise a target state, and the gap analysis of the difference. This gap analysis is what drives the Opportunities portion of the Architecture Development Model (ADM). Further, the findings from the gala analysis phase will determine how many interim architecture states might be required to achieve the target state.


Once the Opportunities have been assessed, Architectural Processthe process of assessing solutions can commence. In simple terms, that is building out the list of Business Capabilities that need to be Created, Reduced, Updated, or Deleted in order to achieve the target state. CRUD is a common means of describing the various types of change Business Information can have. This is the Business Transformation process that is typically led by the Agile EA.

The Agile EA must develop the various views of the proposed architecture for consumption by the Business Stakeholders, attaining consensus on the architecture, and making modifications as the Goals and Objectives of the Executive change. Once the Executive has agreed to the target architecture, the various financial aspects of the architecture are examined, typically in the form of a Cost/Benefit Analysis (CBA).

At that point, assuming the CBA is approved for funding, the target architecture is normally handed over to the Project Management Office (PMO) to begin looking at defining the overall Programs – which may cross between different Business Units. Then the various components are broken down into Projects – each with its own Scope, Budget & Resourcing requirements.

06413-pmlc_25252b_clapThis process is pretty clearly defined in the CLAP Framework. Please note that the CLAP framework was later replaced with CLIP, to account for Information, as well as doing a better job of describing the how the Business Processes must map to Business Capabilities. Further, this is well-described in the Archimate modelling language, in the Implementation Extension.

The Cloud – Platform as a Service

In the previous post of this series, we took a look at Software as a Service (SaaS). We saw how that is what end-users most commonly think of when they think of The Cloud – mostly because that is how it is marketed by some of the big retail players, like Microsoft and Apple. But in the commercial space, it is a very different story.

In the commercial space, IT Operations is changing its business model. The term The Cloud more refers to a collection of IT standards – Virtualization, Service Catalog, Automation and Orchestration. Then finally, the discussion of whether or not to host on-premise or off-premise. This is The Cloud IT Operations managers think about.


In a nutshell, Virtualization is creating an environment where a single physical compute node (think processor, memory and disk resources) can be utilized by more than a single operating system. This allows those resources to achieve a much higher rate of utilization, which in turn provides financial efficiency to the IT Operations.

The Service Catalog is a collection of common settings used to describe how the compute default_service_catalog_homepagenode’s resources are set up, what operating system gets installed & configured, and what other software needs to be installed & configured. So instead of purchasing a new piece of server hardware for every project, an IT Manager will provision a Virtual Server, configured in accordance with one of the options from the Service Catalog. Here is an example, which is the Service Catalog from ServiceNow. They provide SaaS for the Service Catalog itself !


The Automation component comes in when the Service Catalog is exposed to the consumer, who can select what they want, optionally pay for the resources they are about to use, and the Systems Manager deploys the Virtual Server in accordance with the options. There is no human intervention to deploy the system, unless there is an approval phase, whereby the provider of the system must approve the use by the consumer – this is often done in Enterprise settings.

The most complex offering includes Orchestration. A Business System is made up from a number of different services, which may reside on different types of hosts in the Service Catalog. 020200For example, a simple eCommerce solution will have a web-based presentation layer, and JAVA based intelligence layer, and a database providing the persistence layer. These are deployed on different types of server in the Service Catalog. As such, orchestration allows the Consumer to select a group of options from the catalog, which will then automatically provision the required Virtual Servers, as well as the required connectivity between them.

This collection of Virtual Servers creates the Platform that consumers would then use to deploy their applications to. They need have no knowledge of hardware, virtualization, operating systems, networks or storage. They simply build & upload their application components – HTTP files for the presentation layer, JAVA files for the business intelligence layer, and the database definitions for the persistence layer. Hey presto – they have an app running “in the cloud” !

In the end, the Consumer pays for the traffic to & from their new web-site, as well as the processing time & storage used, all in a tidy monthly package. And that package was pre-defined in the provider’s Service Catalog. This allows the Consumer to focus on the revenue-generating aspects of THEIR business, and leave the IT Operations to the Provider.

Most interestingly, when business consumers generally think of The Cloud, they think of the big players in the space, like Amazon Web Services or Microsoft Azure. Those are called off-premise providers. But all of these technologies are available to be purchased, installed and run inside the consumer’s data-centre. There are a number of solutions which even utilize service both on-premise and off-premise – called Hybrid Cloud solutions.

We have looked at The Cloud from three of the four perspectives. We’ve seen Cloud-Like Services, we have examined Software as a Service, and now Platform as a Service. In our next instalment in this series, we will take a look at Infrastructure as a Service.


Practical TOGAF – The Architecture

TOGAF separates the Enterprise Architecture into four distinct domains – the Business, the Information, the Application and the Technology. The TOGAF 9.1 specification describes each of these domains in four discrete ways – the Objectives, Goals, Inputs and Outputs.

TOGAF-admWhen all four domains are completed, it can be said that there is a complete baseline architecture in place. And that’s really important – to understand “Where are we now ?”. As we progress through the ADM, we come to recognize that one of the goals of the Agile EA is to help the Enterprise adapt to change, whether from external pressures (competition perhaps ?) or internal pressures such as a shift in Business goals.

The next objective of a trip through the ADM, after establishing the baseline architectures, is to identify Opportunities & Solutions. Regardless of the architecture, the method is the same: examine the baseline state, examine the target state and perform a gap-analysis exercise. This represents what is arguably one of the most important parts of the EA’s work – identifying what needs to change and articulating how & why to the stakeholders. This process can bee seen in more depth here.

Once the Opportunities and Solutions are identified, then comes the “Project Phase“. The Agile EA & Stakeholders have agreed on WHAT needs to change, the next phase is Migration and Planning. When we looked at the CLAP Framework, we came to realize that this is pretty straight-forward Project Management stuff – defining a list of the required capabilities that would represent the Minimum Viable Product, identifying the team, and getting consensus around a budget.

Of course, it is important to note that while the Project can proceed with Sprint Planning, there may be multiple components to the Program, as well as a number of interim Enterprise Architectures before arriving at the Target Architecture. Further, the Target Architecture is subject to change as well, rendering it as an Interim Architecture. Hence the ADM is seen as an Architecture Lifecycle (Continuum) that is constantly growing and evolving.

As we have seen in a previous post, the lifecycle of a Project is a beast unto itself !

Now that we have a handle on the basic process, we’ll next dive a little deeper into the four areas of Architecture, recognizing that the Application Architecture is sub-divided into Application and Information components.


Create a free website or blog at

Up ↑