Digital transformation using business architecture

Some dramatic “disruptions” are occurring pushed by very young and very innovative companies, forcing more traditional corporations to react with digital transformation initiatives. It is not a surprise that Gartner mentions that “90% of corporate leaders view digital as a top priority,” and that yet “83% of leaders struggle to make meaningful progress on digital transformation.”

Various, agile methodologies are put in place by autonomous IT teams to accelerate the pace of digital transformation. Yet alone, agile practices often struggle to fulfill the business strategies and goals of their company. As I’ve written in a previous whitepaper, “Lean and agile developments and architecture may seem to be two conflicting approaches to deliver software initiatives as first glance. In reality, they can be very complementary. Agility allows very quick reaction times and expedient delivery of initiatives in a continuous flow, which is a necessity in quickly changing corporate environments. Using an analogy, agility allows you to run extremely quickly. Architecture, on the other hand, allows you to see far enough so that you do not hit a brick wall at full speed, while you’re running with agility.”

Benchmark Consulting

Companies that are using and making available their enterprise and business architecture roadmaps within their organization understand a lot better the power of business architecture to communicate adequately with their business and IT stakeholders and deliver customer-driven initiatives in conformity with the organization’s strategies, shown in Figure 1 above and as explained in this blog entitled “The Strategy Execution Metanoia.”

Digital transformation using architecture involves mostly the following steps: business architecture, roadmap development and agile delivery of solutions.

Business architecture

Business architecture involves the following steps:

1. Clarify and disseminate goals and strategies top-down and horizontally using Business Model Canvas (as described in this article entitled “Bridging Business Model Canvas and Business Architecture”), Customer Value Mapping, Customer Journey Maps and/or the Business Motivation Model linking them at minimum to value streams and capabilities;
2. Provide value using Value Propositions, customer-driven Value Streams and Value Stages (each value stage linked to one or several steps of a Customer Journey as described in this article entitled “Optimize Your Customer Journeys Using Personas and Business Architecture”);
3. Prioritize capabilities by examining in detail the enabling capabilities of a value stream;
4. Assess and measure the problematic capabilities that are enabling a customer-driven value stream;
5. Identify the gaps of each problematic capability of a customer-driven value stream from its “as is” state to its desired state;
6. Elaborate expected initiative outcomes for each problematic capability; and
7. Only then should a final program/project roadmap be selected.

Roadmap development

Contrarily to business architecture, roadmap development is a well-known subject within enterprise architecture practices in corporations. As shown in Figure 1 above, I suggest that the roadmap development steps be as followed:

1. Problematic capabilities examined and measured in business architecture should be cross mapped with their enabling software applications/systems and sometimes to their other IT or non-IT assets, especially for initiatives involving Internet of Things technologies;
2. All possible project scenarios delivering expected outcomes should be examined technically and budgeted revenue and costs;
3. Roadmap for each scenario should also be elaborated;
4. Each scenario should then be evaluated based on targeted objectives and goals, financial criteria and various risk factors; and
5. Only then should a portfolio/program/project roadmap be selected.

Agile delivery of solutions

As explained in this article entitled “Providing Access to your Business Architecture Model: the Key to an Agile Digital Transformation” the business and enterprise architect’s job does not end once the roadmap has been selected. Good architects will always make sure to make their detailed architecture model available to those involved with the delivery of programs, projects and sprints, by building relationships with high level business processes, business requirements, epics and even user stories.

As shown in Figure 1 above, I recommend that an agile delivery of solutions include the following two steps:

1. Align the business and enterprise architecture elements (capabilities, information concepts, organization, applications, etc.) involved with the selected roadmap to the business rules and business process to identify the one that will need to be modified, eliminated or changed – saving business process experts a lot of time; and
2. Build your business requirements, epics and user stories based on the business and enterprise architecture elements (capabilities, information concepts, organization, applications, etc.) involved with the selected roadmap before starting your sprints and interfacing with business stakeholders, allowing business analysts and software developers to be a lot more efficient in reaching the business strategies and objectives of their organization.

Conclusion

Corporations are investing like never-before in the digital transformation of their organization. Yet more often then not, they do not have much or enough to show for it. IT-driven agile teams tend to work in silo from the rest of their colleagues and too often they do not deliver according to the business strategies and objectives of their company. Enterprise and business architecture must be used early on at the planning stages of an agile program/project first to minimize the time that can be wasted between business stakeholders and business analysts while gathering information, second to lower significantly the number of agile iterations before the delivery of solutions that really meet the business strategies and objectives of the enterprise, and finally to make sure that agile teams from different programs/projects do not deliver conflicting or partly redundant software solutions.