Most organizations operate at a fast pace of change. Businesses are constantly evaluating market demands and enacting change to drive growth and develop a competitive edge.
These market demands come from a broad number of sources, and include economic changes, market trends, regulations, technology improvements and resource management. Knowing where the demands originated, whether they are important and if they are worth acting on can be difficult.
We look at how innovation, enterprise architecture and successful project delivery needs to be intertwined and traceable.
In the past, managing ideation to the delivery of innovation has not been done or has been attempted in organizational silos leading to disconnections. This in turn results in change not being implemented properly or a focus on the wrong type of change.
How Does An Organization Successfully Embrace Change?
Many companies start with campaigns and ideation. They run challenges and solicit ideas from within and outside of their walls. Ideas are then prioritized and evaluated. Sometimes prototypes are built and tested, but what happens next?
Many organizations turn to the blueprints or roadmaps generated by their enterprise architectures, IT architectures and or business process architectures for answers. They evaluate how a new idea and its supporting technology, such as SOA or enterprise-resource planning (ERP), fits into the broader architecture. They manage their technology portfolio by looking at their IT infrastructure needs.
Organizations often form programme management boards to evaluate ideas, initiatives and their costs. In reality, these evaluations are based on lightweight business cases without the broader context. Organizations don’t have a comprehensive understanding of what systems, processes and resources they have, what they are being used for, and how much they cost and the effects of regulations.
Projects are delivered and viewed on a project-by-project basis without regard to the bigger picture. Enterprise, technology and process-related decisions are made within the flux of change and without access to the real knowledge contained within the organization or in the market place. IT is often in the hot seat of this type of decision-making.
Challenges Of IT Planning
IT planning takes place in reaction to and anticipation of these market demands and initiatives. There may be a need for a new CRM or accounting system, or new application for manufacturing or product development.
While IT planning should be part of a broader enterprise architecture or market analysis, IT involvement in technology investments are often done close to the end of the strategic planning process and without proper access to enterprise or market data.
The following questions illustrate the competing demands found within the typical IT environment:
How can we manage the prioritization of business, architectural-and project-driven initiatives?
Stakeholders place a large number of both tactical and strategic requirements on IT. IT is required to offer different technology investment options, but is often constrained by a competition for resources.
How do we balance enterprise architecture’s role with IT portfolio management?
An enterprise architect provides a high-level view of the risks and benefits of a project and the alignment to future goals. It can illustrate the project complexities and the impact of change.
Future state architectures and transition plans can be used to define investment portfolio content. At the same time, portfolio management provides a detailed perspective of development and implementation. Balancing these often-competing viewpoints can be tricky.
How well are application lifecycles being managed?
Application management requires a product/service/asset view over time. Well-managed application lifecycles demand a process of continuous releases, especially when time to market is key.
The higher level view required by portfolio management provides a broader perspective of how all assets work together. Balancing application lifecycle demands against a broader portfolio framework can present an inherent conflict about priorities and a struggle for resources.
How do we manage the numerous and often conflicting governance requirements across the delivery process?
As many organizations move to small-team agile development, coordinating the various application development projects becomes more difficult. Managing the development process using waterfall methods can shorten schedules but can also increase the chance of errors and a disconnect with broader portfolio and enterprise goals.
How do we address different lifecycles and tribes in the organization?
Lifecycles such as innovation management, enterprise architecture, business process management and solution delivery are all-necessary but are not harmonized across the enterprise. The connection among these lifecycles is important to the effective delivery of initiatives and understanding the impact of change.
The enterprise view, down through innovation management, portfolio management, application lifecycle management and agile development represent competing IT viewpoints that can come together using an ideas to delivery framework.
Agile Development And DevOps
A key component of the drive from ideas to delivery is how strategic planning and the delivery of software are related or more directly the relevance of Agile Enterprise Architecture to Devops.
Devops is a term that has been around since the end of the last decade, originating from the Agile development movement and is a fusion of Development and operations. In more practical terms it integrates developers and operations teams in order to improve collaboration and productivity by automating infrastructure, workflows and continuously measuring application performance.
The drivers behind the approach are the competing needs to incorporate new products into production whilst maintaining 99.9% uptime to customers in an agile manner.
To understand further the increase in complexity we need to look at how new features and functions need to be applied to our delivery of software. The world of mobile apps, middleware and cloud deployment has reduced release cycles to weeks not months with an emphasis on delivering incremental change. Previously a business release would be every few months with a series of modules and hopefully still relevant to the business goals.
The shorter continuous delivery lifecycle will help 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 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:
- will minimize software delivery batch sizes to increase flexibility and enable continuous feedback as every team delivers features to production as they are completed.
- has the notion of projects are replaced by release trains which minimizes batch waiting time to reduce lead times and waste.
- has a shift 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.
Figure 1: DevOps lifecycle
Thus 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. Figure 2 shows how the strategic planning lifecycle supports an ‘ideas to delivery’ framework.
Figure 2: The strategic planning lifecycle
You can see here, the high level relationship between the strategy and goals of an organization and the projects that deliver the change to meet these goals. The enterprise rrchitecture provides the model to govern the delivery of projects in line with these goals.
However we must ensure that any model that is built must be just enough EA to provide the right level of analysis and this has been discussed in previous sections of this book regarding the use of Kanban to drive change.
The Agile EA model is then one that can both provide enough analysis to plan which projects should be undertaken and then to ensure full architectural governance over the delivery. The last part of this is achieved by connecting to the tools used in the Agile space.
Figure 3: Detailed view of the strategic planning lifecycle
There are a number of tools that can be used within Devops. one example is the IBM toolset, which uses open standards to link to other products within the overall lifecycle. This approach integrates the Agile enterprise Architecture process with the Agile Development process and connects project delivery with effective governance of the project lifecycle and ensures that even if the software delivery process is agile the link to Goals and associated business needs are met.
To achieve this goal a number of internal processes must interoperate and this is a significant challenge, but one that can be met by building an internal centre of excellence and finding a solution by starting small and building a working environment.
The Strategic Planning Lifecycle Summary
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.
The ideas and requirements are rationalized into a value proposition that can be examined in more detail.
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. An enterprise architecture is a living thing with a lifecycle of its own.
Figure 3 shows the ongoing EA processes. With the strategy and transition plan in place, eA 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. 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.
If we’re not doing things the way we said we want done, then we must ask if our target architectures are still correct. This helps keep the EA current and useful.
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. Then the transition plan is examined to see if it is still moving us in the right direction. If not, it is updated.
Figure 3, separates the organization’s strategy and vision, the enterprise architecture lifecycle components and the solution development & delivery. some argue that the strategy and vision are part of the EA while others argue against this. Both views are valid since they simply depend at how you look at the process.
If the CEO’s office is responsible for the vision and strategy and the reporting chain as responsible for its execution, then the separation of it from the EA makes sense. In practice, the top part of the reporting chain participates in the vision and strategy exercise and is encouraged to “own” it, at least from an execution perspective.
In that case, it might be fair to consider it part of the EA, or you can say it drives the EA. The categorization isn’t as important as understanding how the vision and strategy interacts with the EA, or the rest of the EA, however you see it.
Note that the overall goal here is to have traceability from our ideas and initiatives, all the way through to strategic delivery. This comes with clear feedback from delivery assets to the ideas and requirements that they were initiated from.