Your Enterprise Architecture is the sum total of your technology capabilities that is used to derive profits for your company. In a digital world, it's the engine for how your company competes and how it manages its daily operations.

While Digital Business Transformation (DBT) initiatives, where you are reimagining the future of your business, could feel like delivering projects and products -- what is really happening underneath is that an image of your transforming business is being created in software. And this image is represented by your Enterprise Architecture.

Through your technology transformation, your EA is moving to its to-be state as capabilities are added, removed and improved. The hope is that your EA will be an asset that is flexible and easily adaptable to new needs; that it is highly performant, scalable and secure - but not overdone (e.g. over-provisioned and underutilized)  to be wasteful.

But that’s not going to happen if you don’t have a clear plan for where you are going with your EA.

To get the most economic value from your EA asset, you need to groom it carefully, attending its ability to support future directions and not just letting the goals of individual DBT projects tug it in this direction and that.

It’s not clear to me why many traditional, stodgier companies don’t have an actual plan for their EA as part of their DBT. Sure, there might be a to-be schematic to help architects visualize systems, their integrations, their infrastructure, their data flows, etc; but they’re often misused to obfuscate, bore, and show an ability to comply with expectations.

If I want to see the truth about the EA of a business, and where it’s going during DBT, I’d rather see an EA plan that has 5 components to it.

1. Truth
2. Assertions
3. Skills
4. Money
5. Measurements

Truth

The truth section describes the world as it is. In addition to the obvious architectural viewpoints and perspectives, it describes the following:

• Business needs that exist and the solutions that exist to address those needs
• Milestones that mark key changes in the EA as it evolves through the product lifecycle. This includes successes and failures that led up to the current state
• Technical debt, which represents flaws in the EA asset; the stuff that will cause future work to be non-agile, slow and expensive.
• Cost Optimization, which describes how efficiently systems are able to run to deliver business value at the lowest possible price point

Assertions

The Assertions section is where you describe how you are going to change things through your DBT. This is the heart of the EA plan. Here you need to capture what you’re going to do and what impact it’s going to have. This will contain many forward looking promises that might not be met, so you also want to capture the alternatives in case that happens.

For the typical Technology transformation, the assertions section might describe what you will do to be in a to-be state where you are seamlessly:

• Making frequent, small and reversible changes to iterate rapidly without affecting customers as much as possible
• Auto-scaling up and down your cloud capacity to optimize your costs while meeting business demands
• Creating and tearing down production-like environments in order to test systems at a production scale
• Automating replication of entire systems to make architectural experimentation easier
• Making fact-based decisions based on the behavior of your workloads, in order to drive architectural decisions using data
• Performing operational procedures as code to limit human errors and enable consistent response to events
• Consistently reducing defects, easing remediation and improving flow into production
• Consistently capturing and analyzing the health of your operations events so you can take appropriate action
• Automating software-based security mechanisms to improve your ability to securely scale more rapidly and cost effectively
• Automatically repairing and recovering from failures
• Protecting data at rest and at transit
• Democratizing advanced technologies for consumption by product development team

In this section, you also want to describe the principles and practices that your architects, whether they are part of a centralized EA team or distributed within your business capabilities, will use to manage and choose between the manifold of trade-offs and tactical decisions that must be made to cultivate your EA asset.

Skills

This section is the abstracted sum of all the skills that will determine how agile your EA will be in the future. Skills can promote or impede the progress of your EA vision, and in turn the progress of your DBT. Skills can raise or lower the costs and time needed to get a change to market. For example, if you don’t have great DevOps skills, then the quality and cycle time of bringing capabilities to market will suffer until you have them.

In this section you want to highlight the key elements of what skills do you have on your team and what skills are you going to bring to your team to bring to life the future vision for your EA.

Money

This section is all about money. How much do you need, how will you spend it, profit and loss and margins. It talks about how each investment dollar will actually move the EA forward in the direction of your DBT vision. After all EA must be treated like any economic asset in your organization.

Here you describe how you will be able to build architectures in which you can do the following:

• Ensure that your infrastructure and engineering skills usage and costs move in line with demand
• Use appropriate cloud services and resource types to minimize costs
• Analyze and attribute expenditure of technology and skill costs to individual workload owners
• Reduce costs over time

The scope of this section should cover how you will think about managing cost from proof of concepts for the business products and capabilities to the ongoing operation of production workloads.

Measurements

The final section is about measurements. Ultimately your EA vision needs to result in improvements in your short and long term Software Development and Delivery Performance.

Describe what KPIs and benchmarks you will have to measure performance against your assertions:

• Software Development performance benchmarks and targets such as lead time for features and Deployment frequency
• Software Deployment performance benchmarks and targets such as change failure rate and time to restore service
• Service Operation Performance benchmarks and targets such as availability

Conclusion

Too often, we get hung up on Enterprise Architecture as defining, ensuring consistent standards, methods and communication between architects. But as technology leaders, where we are trying to transform our business for a digital world, we need to steward the asset that is our Enterprise Architecture in a way that is aligned to our company’s business transformation. And an EA plan such as one outlined here might better help us get there.