Whitepaper written by Daniel Lambert

You're starting your business enterprise architecture practice? Do you feel your enterprise and business architecture is not performing to its full capacity? In this whitepaper, you will learn seven tips on how to increase the odds of success of your business architecture practice within your organization. You will learn how to find a top management sponsor, how to build your team, how to get buy-in from your ecosystem, how to integrate business architecture within your current enterprise architecture, how to schedule and deliver your business architecture practice implementation toward your first success, how to calculate your return on investment after the completion of your first mandate, and finally how to grow and have a greater impact on your organization.

1- How to Find a Top Management Sponsor?

In brief, to find a good management sponsor to support the creation of a useful business architecture practice within an organization, you need to build a good elevator pitch. Second, you should not be afraid to talk about money.

Ideally, the COO of your organization or one of its business units should be a very good sponsor, but it’s not always possible to have one. In such cases, you can fall back to a CIO, if the person is business strategic oriented. The reason for insisting to have top management sponsorship is that some of the tough digital transformation decisions need to be driven top-down. I’m afraid to say that there is only so much that can be lead through grassroots activities. Changes to enterprise standards, policies, and governance require top management sponsorship to be acknowledged and delivered with success. To have success with your business architecture practice, you will also need a sponsor that can help you open doors within your organization so that you can gather the necessary information to complete your tasks. A good sponsor will not leave you alone. This person will follow up with you at regular intervals. Finally, a good sponsor will expect results rapidly; especially at the beginning. You should not tackle a too complicated and long-term business problem at the beginning. Put the odds on your side by selecting a first initiative that can be planned and delivered rapidly. If you do not have a good sponsor, odds are high that you’ll be left in a corner crafting beautiful plans, strategies, tactics, and an architecture model that will not reflect the reality of your organization and that will most probably end up gathering dust.

A good elevator pitch to attract your sponsor should first include a problem that’s nagging your sponsor. This way, you will get its full attention for a few minutes. If you talk about general problems that do not relate to one of the sponsor’s pain, odds are low that you’ll get any responsiveness. Once you have the sponsors’ attention describe what you can do briefly and precisely, without getting technical. You can then outline how much your practice would cost, and finally, elaborate on what the planning and delivery of your first initiative would generate or save.

Finding a problem nagging your potential sponsor is imperative. Do your homework. Find out if projects are always delivered late, delivered projects are not strategic enough, your competitors have a better product offering, your losing market share, promised synergies of an acquisition are not happening, for example.

I often find very useful strategic information about an organization in its annual reports. For example, odds are high that you’ll find a pertinent problem in the organization's annual report, and/or 10k. Most public service organizations also publish annual reports often hidden somewhere on their website. Google the right words and you will most probably find it.

When you’re describing what you can do, you should avoid talking about capabilities, value streams, applications, and stakeholders. You should instead talk about the following:

  • Increasing business strategy execution
  • Fixing priorities based on business strategies
  • Eliminating siloes and increasing communication between business and IT or between departments
  • Simplifying the complexity of your interactions with your clients and partners
  • Contributing to the delivery of projects with better and more precise planning and lower the risk of project failure
  • Etc.

While outlining how much your practice would cost in your elevator pitch make sure to provide a number that you can beat, have preferably a small team, to begin with, and do not talk about details (but be prepared). Finally, while elaborating on the amount of money that you’ll generate or save, you should outline briefly how much money the tackled problem or initiative will generate or save, you should not talk about details (but be prepared), and finally, make sure that this number is much higher than the cost to implement your practice.

2- How to Build your Team?

Here’s your chance. You’ve found your sponsor and you're ready to build your team. What should you do to make this right? Each member of your team should have most of the following 7 compelling required qualities, as mentioned in this article I wrote a while back in CIO.com entitled "7 compelling qualities of business and enterprise architects"[1]:

  • Customer-Driven. Complete business and enterprise architects understand that their organizations must become customer-driven, where different business units within their organization that used to work independently in the past must now collaborate to innovate their business, products, and services.
  • Excel at Finding Value. Talented business and enterprise architects may be good at finding cost reductions by examining, for example, redundancies in the number of applications that fulfill a capability, but they also excel at finding and explaining value for their organization and customers while examining innovations.
  • Good Communicators. Business and enterprise architects are also extremely good listeners. The scenarios that enterprise and business architects build for any initiative are the results of multiple meetings on both sides of the fence, business, and IT. During initial meetings, enterprise and business architects mostly listen and extract relevant issues and information that matters.
  • Not an Enterprise & Business Architecture Model Freak. Business and enterprise architecture models should be a simple question-answering device easily accessible internally with a browser. Aiming for a quick time-to-value, good architects can build a model that contains as many details as needed to answer questions from both the business and technical side of their organization for a given initiative, but nothing more.
  • Know Measurement Techniques Inside Out. Good enterprise and business architects know that building a business Architecture model without measuring any of its key elements is a pure waste of time. Enterprise and business architects also understand the need for strategic and tactical measurements, and how to have effective measurements (KPIs) in place with proper diagrams.
  • Meeting the Organization’s Objectives. Talented Business and Enterprise Architects know how to meet both the tactical and strategic objectives of the organization. Business and enterprise architects can both advise on short-term questions or provide a long-term business-oriented roadmap for IT and its business systems.
  • Involved in Delivery. The business and enterprise architect’s job does not stop at producing roadmaps and assisting corporate management in the selection of an optimal scenario. In many organizations, still today, only 25% to 30% of business transformation initiatives are successful over the long term as shown in many studies mentioned in my book. These studies all indicate that transformation projects fail short of their objectives and drag far too long because the coordination and architectural bridges between business and IT stakeholders are none existent. This is why good enterprise and business architects will always make sure to make their detailed enterprise and business architecture models available to those involved with the delivery of tactical projects or strategic initiatives. This will allow delivery teams to stop defining requirements, epics, and user stories from a blank page, but instead, use elements from the business architecture or their organization. This method will be quicker, more precise, and less risky.


To build your team, you should have a combination of the following: 1- experienced business architects hired from the outside of the enterprise, 2- business stakeholders converted into business architects, 3- experienced enterprise architects with an IT background. At least one of each would be ideal, as shown in Figure 1 above[2].

An experienced business architect should accelerate the time to deliver results and value and be able to assist in establishing the foundation of your business architecture practice. You should make sure that the person is aware of common standards (BIZBOK, TOGAF, common strategy methods, etc.). You should also be aware that it will require this newcomer time to learn about the company and establish credibility.
Converting a business employee into a business architect is also a good idea. It will save time learning about the firm, allow a tighter integration and adoption with business stakeholders, and expand the range of the team. Also, note that learning BIZBOK and TOGAF will take a while for a business stakeholder. You also need to make sure that the person can scale to higher-level and structured thinking. Finally, converting an IT architect into an enterprise or business architect is also extremely recommended. It will also save time learning about the firm, allow a tighter integration and adoption with business stakeholders, and expand the range of the team. Also, note that for this person learning BIZBOK will take a while. You will also need to make sure that the person can scale to higher-level and structured thinking.

You should also take into account other sourcing considerations. Diversity is always preferable to homogeneity. Hiring one from each sourcing option initially will increase your odds of being successful. Experienced enterprise architects, business strategists, business analysts can make very good business architects.

3- How to Get Buy-In from your Ecosystem?

To provide real value to your organization, your business architecture firm must be able to bring people together in whatever way works. In other words, your team needs to get buy-in from its ecosystem, as shown in Figure 2 below.


With step 1 "Business Design and Strategy", you will often need to collaborate with CXOs, Head Office Strategists, Business Unit Executives, Business Managers, and Change Managers. In step 2 “Architecting Transformation”, you will often need to collaborate with Clients, Partners, Subject Matter Experts, Business Managers, Change Managers, Product Managers, Marketers, and Data and BI Architects. As for step 3, “Initiative Planning”, you will often need to collaborate with CIOs, Program Managers, Portfolio Managers, Financial Analysts, Applications Architects, Solution Architects, IT Architects, and sometimes with Software Architects. In step 4, “Agile Delivery & Execution”, business and enterprise architects will often need to collaborate with Clients, Partners, Users, Agile Experts, Business Process Experts, Business Analysts, Software Developers, IT Architects, and Software Architects. As for the last step involving various sorts of measurements, it can occur at any of the 4 previous steps, but ultimately you will need to know if your projects have been successful at reaching your strategic goals and objectives. Here, you will often need to collaborate with clients, partners, head office strategists, and finance managers.

There are several reasons why your collaborators will want to assist you, as mentioned here:

  • You are sponsored by someone important and respected within your organization,
  • They will have access to the work you are doing (initiatives, scenarios, costing, data, etc.),
  • They will want to be part of your success, and
  • Foremost, your efforts will improve their own work.

4- How to Integrate Business Architecture within your Current Enterprise Architecture?

There are several ways to integrate business architecture within your current organization and enterprise architecture.

Business Architecture Under Enterprise Architecture. Business Architects will often be in the Enterprise Architecture department ordinarily under the CIO, as shown in this diagram. They may be called business architects, enterprise/business architects, or even enterprise architects. Here, business architects will report to the Enterprise Architecture leader (most likely within IT) along with the IT architects that often will have an Enterprise Architect title. This way of operating creates a shared vision, consistent practices, and integrated architecture among business and IT architects, but it will often have a drawback. Business architects may be perceived as separate from the business units supported and as an IT perspective only.

Business Architecture Under the CIO. It is becoming more frequent to have business architects in a separate group from enterprise architecture still often in the IT department under the CIO. In this case, Business architects report to a leader within IT outside Enterprise Architecture. The main benefit and inconveniences are the same as business architecture under enterprise architecture. There is here an additional inconvenience since this org chart may lead to inconsistent practices or lack of integration between business and IT architecture.

Business Architecture within Governance. I’ve also sometimes seen business architecture reporting to a Chief Governance Officer. Here, business architects are staff as part of the governance group. This should create a shared vision, consistent practices, and integrated architecture among business architects, but as the inconvenience of making it more difficult for business architects to be involved in the planning of IT delivery of initiatives and projects. They can be perceived as outsiders to both business and IT stakeholders.

Business Architecture Under the COO. This will not be as frequent, but it is possible to have the business architecture team reporting to the Chief Operating Officer. In this case, business architects report to a leader(s) within the business. It creates a tighter integration with and acceptance by the business. The inconveniences are that first, business architects may be perceived as separate from the IT architecture disciplines, and second, it may also lead to inconsistent practices or lack of integration between business and IT architecture.

Should you centralize or decentralize your business architecture team? The benefits of a centralized team are that it creates consistent practices and integrated architecture, and it is simpler to manage. It has the inconvenience of being perceived as separate from the business units supported. The benefit of a decentralized team split into many business units is that it creates a tighter stakeholder integration and acceptance. The inconvenience is that it may lead to a lack of integrated architecture, it may also dilute the business architecture role by adding additional responsibilities, and it is more complex to manage. A hybrid team creates both a more consistent practice and a tighter stakeholder integration and acceptance, but it has the inconvenience of being a more complex structure to manage.


Most organizations serious about their business transformation will have some kind of strategic business transformation governance committee reporting to the COO of the organization, as shown in Figure 3 above. Ideally, business and enterprise architects should be involved in this committee as core participants. They should work with other core participants, like change managers, strategy experts, etc.

Depending on the examined initiatives, virtual participants should also be involved. Business stakeholders from different business units should be among virtual participants, like subject matter experts, product managers, and marketers. The architect team reporting to the CIO should also be involved as virtual participants, like EAs, application architects, data architects, for example, depending on the examined initiative.

5- How to Schedule and Deliver your Business Architecture Practice Implementation Toward your First Success?

If you’re beginning your practice within your organization, how can you schedule and deliver your business architecture practice implementation toward your first success?

Business and enterprise architects should not try to map and assess five-level deep all business capabilities of an organization all at once. They need to prioritize and focus in detail on strategic capabilities that will provide value to both clients and the bottom line of their enterprise. The first initiatives and projects should provide positive results within 3 to 6 months from business strategy all the way to agile software/IT delivery planning, as mentioned in Figure 4 below. You should focus on low-performing and high-priority business capabilities first. You should consider your job completed only when you have assisted in the detailed planning of agile project deliveries.


In phase one, you need to organize your future practice and select your initial initiative or project. The business stakeholder is identified and has accepted to be your sponsor. You have credible business subject-matter experts that can guide you through your planning. You have a good sounding board for governance. You have two to four business and/or enterprise architects in your team initially. Roles and responsibilities are defined. The initiative is selected. Relevant and existing data is gathered. You’re getting preliminary feedback from your ecosystem.

In phase 2, you need to move from business strategies to a roadmap selection. You first need to name and describe business capabilities relevant to your initiative one to 3 levels deep. You need to complete the value streams corresponding to your project or initiative, with their enabling capabilities. You need to assess or measure these capabilities and find their supporting applications if any. More precisely you need to prioritize, measure their performance, and find out the business complexity of each one of these capabilities. You need also to identify the gaps and expected business outcomes of each gap. In an ideal world, you’ll focus first on the high priority, low performing, and low business complexity capabilities first. Only then will you be able to build roadmaps with sufficient details and including a budget for several scenarios. Based on financial and risk criteria, you will be able to select the final scenario and roadmap that will need to be delivered by IT.

Your job as an EA or business architect is not done. In phase 3, you need to assist the IT delivery team in planning in more detail each portion of the roadmap. You need to define requirements, epics, and user stories using elements from your business architecture model. This will avoid blank pages, accelerate planning, and lower the risk of execution. Once the delivery of each portion of your project is ready you need to measure if business outcomes have been reached. Once your project has officially been launched, you finally need to measure ROI and your success. If your sponsor is satisfied, many additional initiatives and projects will start appearing your way and you will need to grow your practice within your organization.

6- How to Calculate your Return on Investment after the Completion of your First Mandate?

It’s imperative that you calculate the ROI of your project after the completion of your first project, as shown in Figure 5 below. Other financial metrics can be used instead of the ROI ratio. This calculation needs to be done with someone in finance within your organization. To achieve a high ROI, cash entries and revenue need to be higher than expenses. Time is also important. The quicker your revenue can occur the higher your return will be. The later your expenses occur, the higher your ROI will be.


Costs or expenses will usually involve business and enterprise architects, some necessary training, and the use of a collaborative software application. Initially. the cost of your business and enterprise architects should be much lower than $800k. You will also need training and maybe some consulting. Often, you will be told by consultants that the need for a tool can wait. This way, they can take a larger portion of your budget. There is only so much you can do with Excel, Visio, or an antiquated EA tool. These tools do not allow you to scale and collaborate with your ecosystem. I would advise you on getting yourself a business architecture tool early and cut instead of your consulting budget.

Your business architecture practice will generate 3 types of benefits. First, there is the strategic value contribution of your input. This will usually bring additional revenue and profits to your organization. The second benefit will involve strategic and tactical delivery improvement of your initiative. Essentially, IT folks do not waste as much time planning, defining their requirements, epics, and user stories. This benefit alone will usually be sufficient to justify your practice. Finally, the third benefit resides in operational execution improvement, where you will find redundancy in assets, expenses, and salaries.

7- How to Grow and Have a Greater Impact on your Organization?

If you have well-executed the first 6 tips provided in this webinar, it is almost certain that you will grow and have a greater impact on your organization in the future. To grow and have a greater impact, make sure to execute the following:

  • Inform your sponsor knows about your success; odds are high that this person will promote your work,
  • Calculate your ROI (or whatever financial measurement used within your organization). It’s a very good measure of your success, and
  • Get involved with your ecosystem, in particular at the planning of delivery projects. This is where you will provide the greatest return.

In summary, this whitepaper was intended to shed some light on how to improve your business architecture practice and digital transformation within your organization. I really hope some of these tips can prove useful to you, your team, and your organization.

[1] Article entitled "7 compelling qualities of business and enterprise architects" written by Daniel Lambert in CIO.com on August 21, 2018.
[2] Figure inspired by this whitepaper written by Whynde Kuehn entitled "The Business Architecture Team" on Nov. 30, 2017 on the Bizarchmastery.com website.