Some dramatic \u201cdisruptions\u201d 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 \u201c90% of corporate leaders view digital as a top priority,\u201d and that yet \u201c83% of leaders struggle to make meaningful progress on digital transformation.\u201d\nVarious, 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\u2019ve written in a previous whitepaper, \u201cLean 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\u2019re running with agility.\u201d\n Benchmark Consulting\nCompanies 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\u2019s strategies, shown in Figure 1 above and as explained in this blog entitled \u201cThe Strategy Execution Metanoia.\u201d\nDigital transformation using architecture involves mostly the following steps: business architecture, roadmap development and agile delivery of solutions.\nBusiness architecture\nBusiness architecture involves the following steps:\n\nClarify and disseminate goals and strategies top-down and horizontally using Business Model Canvas (as described in this article entitled \u201cBridging Business Model Canvas and Business Architecture\u201d), Customer Value Mapping, Customer Journey Maps and\/or the Business Motivation Model linking them at minimum to value streams and capabilities;\nProvide 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 \u201cOptimize Your Customer Journeys Using Personas and Business Architecture\u201d);\nPrioritize capabilities by examining in detail the enabling capabilities of a value stream;\nAssess and measure the problematic capabilities that are enabling a customer-driven value stream;\nIdentify the gaps of each problematic capability of a customer-driven value stream from its \u201cas is\u201d state to its desired state;\nElaborate expected initiative outcomes for each problematic capability; and\nOnly then should a final program\/project roadmap be selected.\n\nRoadmap development\nContrarily 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:\n\nProblematic 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;\nAll possible project scenarios delivering expected outcomes should be examined technically and budgeted revenue and costs;\nRoadmap for each scenario should also be elaborated;\nEach scenario should then be evaluated based on targeted objectives and goals, financial criteria and various risk factors; and\nOnly then should a portfolio\/program\/project roadmap be selected.\n\nAgile delivery of solutions\nAs explained in this article entitled \u201cProviding Access to your Business Architecture Model: the Key to an Agile Digital Transformation\u201d the business and enterprise architect\u2019s 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.\nAs shown in Figure 1 above, I recommend that an agile delivery of solutions include the following two steps:\n\nAlign 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\nBuild 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.\n\nConclusion\nCorporations 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.