Agile and Enterprise Architecture

Agile & having an enterprise architecture capability

“The real value of enterprise architecture is not in making better architectures…it’s in making a better enterprise” Gary Doucet, Chief Architect, Government of Canada Treasury Board of Canada Secretariat GC. How does enterprise architecture support agile that seems to focus on “light” processes? Are the two concepts in conflict with one another? In my view they complement one another, let me explain….

Functioning in an enterprise echo system

Enterprises have countless programs and projects that span multiple business areas. Each project uses a mix of roles from business and IT that have to work collectively within and across projects to deliver effective business solutions. In most cases this done on an ad-hoc basis and the left hand is unaware of what the right hand does? Project A is unaware of what happens in project B, C, and D etc. Projects are delivered late and budgets are exceeded. This occurs in cases where an enterprise architecture capability with business processes and underpinning application & technology architecture are not managed. Each project then functions in a silo and knowledge harvested during the project in terms of processes, application services, application functions, application components and technology components is lost. Knowledge management does not mean “filing” documents in document management systems!

True agility enables teams to have access to accurate as-is content as modeled artifacts and to move towards to-be artifacts in a collaborative managed environment. This implies that models are not only used in projects, but also in daily operations i.e. managing change requests and service requests.

Typical agile solution delivery process

The above works well when the focus is only on delivering the solution within time and budget. In this scenario, little to no knowledge about the designs of the solution (process & systems) is maintained over the life of the solution. Future changes will have to go through a lengthy discovery process before changes can be realized. This is especially true for corporate solutions that consist of multiple applications that integrate with one another.

Having a business solution delivery capability

For your business solution delivery capability to be effective, it needs:

1. Processes (business solution delivery method i.e. waterfall, iterative, agile etc.) that also covers the HOW i.e. appropriate deliverables, artifacts and building blocks.

2. Knowledge workers who are skilled to define, design, build and test solutions,

3. Supporting tools to manage knowledge creation (requirements and designs), manage application lifecycle, manage quality assurance etc. and

4. Knowledge needs to be managed i.e. process ownership, application portfolio ownership etc.

Just focusing on a method, i.e. agile, will not give you an effective business solution delivery capability!

Having a true enterprise architecture capability where knowledge is managed

In this scenario, it becomes practical to plan across programs and projects and to assess which business processes are in scope across projects. Silo mentality is broken right from the scope phase and the focus is on “making a better enterprise”. Where a business process is in scope in multiple projects, effort can be coordinated to collectively identify objectives, requirements and underpinning solutions. Without this, the chances are good that each project will look at the impacted business process in a silo manner resulting in duplication and rework – not really agile?

Requirements traceability

By aligning the business process with the underpinning application functions (use cases) allows one to have full requirements traceability that includes:

1. Objective / Goal

1.1 Business process and user stories that realizes the objective / goal

1.1.1 Application functions (use cases) and user stories that realize the business process

1.1.1.1 Use case scenarios (test scenarios) and associated user stories and test cases

Use cases exist at different levels of granularity. Alistair Cockburn, leading authority on use cases, describes five levels of granularity (cloud level, kite level, sea level, fish level and clam level).

Integrated agile and enterprise architecture cycle

In this scenario, business processes and associated objectives and requirements are visible and shared across project teams where the business process is also in scope. Effort is now collated and a solution can be designed and developed that realizes the requirements that will make the enterprise better, not just the project.

The above is made possible when one manages knowledge in a robust enterprise architecture platform for projects and daily operations i.e. ARIS Connect & ARIS UML Designer.