How do organizations innovate? Taking an idea from concept to delivery requires strategic planning and the ability to execute. In the case of software development, understanding agile enterprise architecture and its relevance to DevOps is also key.
DevOps, the fusion of software development and IT operations, stems from the agile development movement. In more practical terms, it integrates developers and operations teams to improve collaboration and productivity by automating infrastructure, workflows and continuously measuring application performance.
The goal is to balance the competing needs of getting new products into production while maintaining 99.9-percent application uptime for customers in an agile manner.
To understand this increase in complexity, we need to look at how new features and functions are applied to software delivery. The world of mobile apps, middleware and cloud deployment has reduced release cycles to days and weeks not months — with an emphasis on delivering incremental change.
Previously, a software release would occur every few months with a series of modules that were hopefully still relevant to the business goals.
The shorter, continuous-delivery lifecycle helps organizations:
- Achieve shorter releases by incremental delivery and delivering faster innovation
- Be more responsive to business needs by improved collaboration, better quality and more frequent releases
- Manage the number of applications impacted by a business release by allowing local variants for a global business and continuous delivery within releases
The DevOps approach achieves this by providing an environment that:
- Minimizes software delivery batch sizes to increase flexibility and enable continuous feedback as every team delivers features to production as they are completed
- Replaces projects with release trains that minimize batch-waiting time to reduce lead times and waste
- Shifts from central planning to decentralized execution with a pull philosophy, thus minimizing batch transaction cost to improve efficiency
- Makes DevOps economically feasible through test virtualization, build automation and automated release management as we prioritize and sequence batches to maximize business value and select the right batches, sequence them in the right order, guide the implementation, track execution and make planning adjustments to maximize business value
An Approach with an Enterprise Architecture View
So far, we have only looked at the delivery aspects. So how does this approach integrate with an enterprise architecture view?
To understand this, we need to look more closely at the strategic planning lifecycle. The figure below shows how the strategic planning lifecycle supports an ‘ideas-to-delivery’ framework.
Figure 1: The strategic planning lifecycle
You can see the high-level relationship between the strategy and goals of an organization and the projects that deliver the change to meet these goals. Enterprise architecture provides the model to govern the delivery of projects in line with these goals.
However, we must ensure that any model built include ‘just-enough’ enterprise architecture to produce the right level of analysis for driving change. The agile enterprise architecture model, then, is then one that enables enough analysis to plan which projects should be undertaken and ensures full architectural governance for delivery. The last part of this is achieved by connecting to the tools used in the agile space.
Figure 2: Detailed view of the strategic planning lifecycle
The Agile Enterprise Architecture Lifecycle
An agile enterprise architecture has its own lifecycle with six stages.
Vision and strategy: Initially, the organization begins by revisiting its corporate vision and strategy. What things will differentiate the organization from its competitors in five years? What value propositions will it offer customers to create that differentiation? The organization can create a series of campaigns or challenges to solicit new ideas and requirements for its vision and strategy.
Value proposition: The ideas and requirements are rationalized into a value proposition that can be examined in more detail.
Resources: The company can look at what resources it needs to have on both the business side and the IT side to deliver the capabilities needed to realize the value propositions. For example, a superior customer experience might demand better internet interactions and new applications, processes, and infrastructure on which to run. Once the needs are understood, they are compared to what the organization already has. The transition planning determines how the gaps will be addressed.
Execution: With the strategy and transition plan in place, enterprise architecture execution begins. The transition plan provides input to project prioritization and planning since those projects aligned with the transition plan are typically prioritized over those that do not align. This determines which projects are funded and entered into or continue to the DevOps stage.
Guidelines: As the solutions are developed, enterprise architecture assets such as models, building blocks, rules, patterns, constraints and guidelines are used and followed. Where the standard assets aren’t suitable for a project, exceptions are requested from the governance board. These exceptions are tracked carefully. Where assets are frequently the subject of exception requests, they must be examined to see if they really are suitable for the organization.
Updates: Periodic updates to the organization’s vision and strategy require a reassessment of the to-be state of the enterprise architecture. This typically results in another look at how the organization will differentiate itself in five years, what value propositions it will offer, the capabilities and resources needed, and so on. If we’re not doing things the way we said we wanted them done, then we must ask if our target architectures are still correct. This helps keep the enterprise architecture current and useful.
Enterprise Architecture Tools for DevOps
DevOps can use a number of enterprise architecture solutions. For example, erwin’s enterprise architecture products use open standards to link to other products within the overall lifecycle. This approach integrates agile enterprise architecture with agile development, connecting project delivery with effective governance of the project lifecycle. Even if the software delivery process is agile, goals and associated business needs are linked and can be met.
To achieve this goal, a number of internal processes must be interoperable. This is a significant challenge, but one that can be met by building an internal center of excellence and finding a solution by starting small and building a working environment.
The erwin EA product line takes a rigorous approach to enterprise architecture to ensure that current and future states are published for a wider audience to consume. The erwin EA repository can be used as an enterprise continuum (in TOGAF terms).
Available as a cloud-based platform or on-premise, erwin EA solutions provide a quick and cost-effective path for launching a collaborative enterprise architecture program. With built-in support for such industry frameworks as ArchiMate® and TOGAF®, erwin enables you to model the enterprise, capture the IT blueprint, generate roadmaps and provide meaningful insights to both technical and business stakeholders.
According to Gartner, enterprise architecture is becoming a “form of internal management consulting,” helping define and shape business and operating models, identify risks and opportunities, and then create technology roadmaps. Understanding how vision and strategy impacts enterprise architecture is important – with an overall goal of traceability from our ideas and initiatives all the way through delivery.
