by Daniel Lambert

I seriously doubt that agile initiatives can have success in the long run if they are not supported by an enterprise and business architecture framework that can be reused and enhanced from one project to the next. Digital transformation is not about a one-time change project or about spontaneous business activities. Digitization is more about transforming many dimensions of an organization with a structured approach involving business and enterprise architecture. This article will demonstrate how architecture can ensure success of agile digital transformation initiatives.

Agile Practices in Organizations

Agile practices are increasingly used for the digitization of today’s organizations because business environment demands sound decision making and quick follow through to address global competition treats and rapid market disturbances. According to a 2018 survey entitled “How Agile and DevOps Enable Digital Readiness and Transformation”, about 80% of surveyed organizations have committed to adopting agile practices in their software development. Surveyed companies are using agile practices in most of the principal business functions, as shown in Table 1. Yet some organizations seem to have more success than others.

TSG-full

Although a clear majority of organizations seem to be doing agile in some way, only 18% of them claim to have implemented agile practices broadly, deeply, and consistently across their organization, making them “4.1 times more likely to have the right vision and strategy, and 2.3 times more likely to have a culture to support risk-taking.” All others are somewhat struggling with their agile practice, putting them far away from these numbers. Business and Architecture could be instrumental in increasing significantly the ratio of companies deploying successfully their agile methodologies broadly and consistently everywhere in their organization.

Agile Practices and Architecture

As indicated in this whitepaper entitled “Business Architecture and Agile Methodologies”, the structure and frameworks delivered by a business and enterprise architecture practice can be used to palliate some of the possible shortcomings of projects pursued using agile practices. Agile practices combined to Architecture will avoid many pitfalls.

Agile teams are too often by nature self-organizing and do not always have line of site to other teams’ efforts. This can result in an agile team delivering a project in time and in budget that has considered all specified requirements for a particular group within the organization and yet has failed to consider the interdependencies of their project to other initiatives going on in parallel involving other groups of the organization. Having an enterprise and business architecture practice in place making its framework available to all involved business and IT stakeholders will contribute in closing the external communication gaps that an agile team may experience.

Furthermore, a business and enterprise architecture practice can be very useful in disseminating high level strategies, objectives, and tactics coming from the head office into understandable lower level objectives and tactics relevant to a project, where an agile team is involved. Without business architecture, it is possible that an agile team delivers their initiative with a measurement of value completely aligned to its users and yet completely misaligned to higher level objectives and tactics or the organization. The product owner for an agile team may not see important interrelationships and dependencies that are present and relate his project to higher stakes within the organization. Business and enterprise architecture help identify the relevant value streams and their enabling capabilities related to an initiative, allowing easier information gathering and identification of the needed work efforts or “epics” in Scrum terminology. These epics, aligned to enterprise and business architecture, can now be broken down into agile requirements (user stories, etc.) more easily in the backlog of work to be delivered by the agile team, while lowering the risk of missing important objectives and tactics related to the organization.

TSG-full

Tracing agile requirements constructs to an enterprise and business architecture frame of reference, as shown in Figure 1 above, makes it possible for agile teams to identify more easily the areas that require work within an accepted and well-articulated business perspective. Using business architecture value streams linked to their enabling capabilities (including their relevant measurements), involved business units, and participating internal and external stakeholders, an agile team can prioritize the work according to business leaders’ insights and priorities.

The alignment of epics to value streams, and user stories to capabilities and all relevant element of the organisation frameworks, as shown in Figure 2 below, highlights the requirements and features that require priority focus more precisely, at a quicker pace and at a lower risk of failure for future release planning. As mentioned in this article entitled “Align Your Requirements to Corporate Strategies Using Business Architecture”, the user story in Figure 2 may be longer than usual, but its defined by elements from the enterprise and business architecture framework of the organization described in detail with all relevant relationships. Some of these elements can be capabilities, information, stakeholders, processes, and value streams/stages/items.

TSG-full

The Scaled Agile Framework

Among the most popular and highly scalable agile methodologies used today by large corporations is Scaled Agile Framework® (SAFe®), as shown in Figure 3 below.

In brief, SAFe® is a knowledge-based framework for delivering solutions that deliver business value, scales agile practices, and incorporates lean principles and practices into an organization, as shown in Figure 3 below. This framework provides requirements teams and business analysts with a way to decompose strategic value streams and deliver focused value using 50 to 125 employee Agile release ‘train’ development teams to reduce software development cycle time. SAFe® provides comprehensive guidance to develop better systems and software in large organizations more rapidly. This video, entitled “SAFe 4.0 in 5 minutes”, provides a very good 5-minute explanation. The framework is getting very popular and is generating great results as shown in numerous business cases. It is not surprising that today 60% of US Fortune 100 companies have SAFe® trained practitioners, according to this blog.

TSG-full

There are several reasons why a large corporation will be inclined to use SAFe®. These reasons include:

  • The need to scale the organization’s agile practice at a larger scale;
  • Frequent obstacles, delays, and failures experienced by the organization’s multiple agile teams;
  • Struggling to scale agile activities across the organization’s different business units and departments, where too often the progress in the achievement of the organization’s objectives and tactics vary widely from one agile team to another;
  • Lower lead times of the delivery of the organization’s initiatives.

Aligning SAFe® with Enterprise and Business Architecture

Like SAFe®, enterprise and business architecture aims at increasing an organization’s agility and delivery of real business value in a constant manner. As described in this whitepaper entitled “Aligning Business Architecture and the Scaled Agile Framework”, two focal points among others can be used to align both disciplines: value streams and capabilities.

In SAFe®, a value stream is defined as a “long-lived series of steps that an enterprise uses to provide a continuous flow of value to a customer”. A SAFe’s definition of a value stream includes both an operational and a development value stream. The operational value stream explains the reason an organization is in business and generate profits. Additionally, the development value stream explains how the organization’s systems are architected and implemented to enable the organization’s value offering. The SAFe® operational value stream is extremely to the business architecture value stream explained in the BIZBOK® Guide.

The usage of capabilities in SAFe® and the BIZBOK® Guide shows more significant differences. In SAFe®, a capability is defined as the “higher-level behaviors of a solution at the value stream level”. As for the BIZBOK® Guide, a capability is more what an organization does: “a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome”. In SAFe®, a feature area is a grouping of SAFe® capabilities or a grouping of business outcomes and value. This SAFe® grouping concept is similar to the usage of a capability in business architecture, which is the basic business architecture element linked to so many business objects like value, processes, information, assets and technology, stakeholders, strategies, products and services, business units and departments within an organization.

Early Enterprise and Business Architecture Engagement Preferable

As pointed out in this article entitled “Scaled Agile Framework (SAFe) and Architecture”, enterprise and business architects should start engaging early ideally before the beginning of the SAFe® Scrum and Kanban continuous delivery pipeline by focusing basically in these two tasks. First, enterprise and business architects should make sure to link every value stage of the SAFe® Value Streams to its enabling capabilities, information concepts and its various departments and business units to clarify how the business really works. Second, enterprise and business architects need to translate the business strategic themes into more detailed epics. By putting more resources into business architecture at the beginning of the SAFe® process, odds that the program delivers systems and software more useful to its business users increase significantly.

The modeling executed by enterprise and business architects also facilitates the epic owner’s efforts. When an epic is approved to move from the backlog for review and further business analysis, the epic owner has the responsibility of creating a lightweight business case. This involves examining the size, the impact, and the exact benefits of the epic for the organization. By using the enterprise and business architects’ detailed model, epic owners have a far better understanding of the business scope of their epics and of the benefits the epic will deliver to the organization. This should speed up the business analysis required to expedite the epic to its next phase. This advisory role of the enterprise and business architect within the SAFe® value stream and program levels is not limited in assisting epic owners and business analysts, it can also continue with solution managers and product managers among others.

Conclusion

Agile practices are still maturing. To scale, they require an enterprise and business architecture framework in their organizations. With the other 3 domains of enterprise architecture, the domain of business architecture should be an integral part of implementing a successful agile framework, like SAFe® for example, to bridge the work and communication more smoothly and effectively between the agile development teams and the business stakeholders. By involving business and enterprise architects to perform impact analysis and other forms of modeling at the portfolio level, organizations can identify more detailed and optimal approaches in solving business problems. It is becoming imperative to have business and enterprise architects more involved and collaborate with SAFe® portfolio managers to provide a more precise business context and develop epics that can then be prioritized and developed to deliver projects that are closer aligned to the strategies that matter to business stakeholders. In brief, the addition of business and enterprise architects in an organization will increase the delivery performance of all agile teams in an organization.