Samuel Holcman: Thank you for tuning in to Real Talk. Be sure to join your host Sam Holtzman again for another edition of our program. We'll have more Real Topics of discussion then. Welcome to this edition of Real Talk. I'm Sam Holstman. Thanks for joining me. And the topic for this particular broadcast is the 10 most misunderstood words in enterprise architecture or business architecture and how they cost CIOs and CTOs real money. And by the way, this particular broadcast is also applicable for those of you that are not CIOs and CTOs that are involved in EA and BA. So if you are one of these people, you're already paying an architectural tax that you never approved. What do we mean by that? Well, it shows up as overlapping platforms, programs that cannot finish, strategic projects that are quietly dying after burning millions or billions of dollars. The surprising culprit? Ten everyday EABA words that your organization thinks it understands But we're going to suggest really don't, and are really the cause of what we're talking about here today. When these words are fuzzy, your architecture is fuzzy. And fuzzy architectures are very, very expensive. Let's start with the first phrase that is very much understood, as people think the phrase is understood, but actually isn't. And that's the phrase enterprise architecture. Most executives still hear enterprise architecture and think big centralized IT architecture or solution design on steroids. In reality, enterprise architecture is the architecture of the whole enterprise. Purpose, operating models, enablement structure, goal enablement structure. What the enterprise must be able to achieve and of course related data processes, people, location events and technology. and the relationships between them. That's real enterprise architecture. Why does this cost you money? IT is asked to fix problems that are related to business models and operating model issues. Technology expenditure becomes a patch over structural flaws, creating redundancy, integration debt, and higher total cost of ownership. So if you begin with real enterprise architecture, these costs are avoided. Of course, a related term that is confusing and misunderstood is business architecture. Business architecture is often treated as the business process view of IT. Absolutely not, or a pretty picture of the organization chart. Done properly, it's the explicit representation of how the business achieve its goals. Key goals, its abilities required to teach them and reach them, stakeholders, information concepts. and organizational structures, all tied back to strategic intent and then strategy. Why does this cost you and the organization money? Portfolios are prioritized by the loudest voice. Please forgive me for that, not by contribution to concrete goals. But you know that's real. Projects get funded without a clear line of sight from spending to goal achievement. And IT is blamed later for not delivering the business case. Confusing term number three. Framework. For many organizations, a framework's a logo, a thick book or set of templates. In practice, a framework is a structured way of thinking. It tells you what kinds of things to consider, artifacts, views, and relationships, and how they hang together. It doesn't do the thinking for you, and it does not guarantee goal alignment. It's a thinking tool, not a how tool. And we'll get to that in just a moment. What does this cost money? Teams spend time implementing the framework instead of architecting how the enterprise will achieve its goals using the framework as what it is, a thinking tool. You get shelf wear, tool churn, and framework wars while duplication inconsistencies and misaligned investments continue unchecked. Which brings us to misunderstood term number four, methodology. Methodology is often used as a grand word or understanding of the word process or tool. It's not a grand word. A methodology is a repeatable way of doing things. A methodology is the underlying body of concepts and the reasonings that explain why you do it that way and when to adopt, especially how to connect change initiatives to business goals. Why does the confusion of what a methodology has cost money? Teams follow rituals and templates mechanically, so the quality and usefulness of the architecture work varies widely by project. Every major program reinvents how we do enterprise architecture or business architecture, wasting ramp up time, time, consulting spend, and credibility, and often failing to show how the work actually enables enterprise goals. phrase number five that is misunderstood and one of the most important. Goal enablement. Most organizations assume that if they list goals and run projects, they are quote, aligned. No, goal enablement is something more specific. A clear line from strategic intent to strategy and operational goals to the enduring things the enterprise must be able to do to change the processes, organizations, data, events, and technology. that make those abilities real. Why is this costly? Without goal enablement, you cannot reliably answer the three basic questions. Which goals are we truly designing the enterprise for? What must we actually do to achieve each one of these goals? And third, which investments move the needle on those abilities and which are noise? The result is scattershot spending, local optimization, and dashboards that look very impressive while core goals remain out of reach. Term number six, process. Because everyone lives with processes, the term gets muddled with policies, procedures, and systems behavior. In architecture, a process is a repeatable sequence of activities that transform input into outputs in support of the abilities required, once again, to achieve a specific goal or goals. Why is this costly? Modeling is either at the click level to find a guide investment or at a slogan level, order to cash, with no operational meaning. Automation and ERP CRM programs then lock current inefficiencies in its scale instead of redesigning processes so they actually enable specific business goals. Which brings us to the word strategy, number seven. Inside many enterprises, strategy has become a deck of initiatives, a list of objectives and key results, or a budget. For architecture, strategy should be a set of explicit choices where and how the enterprise will compete, what value propositions it will deliver, which goals matter most, priorities, and with what constraints and risk appetite. Why is this costly in an enterprise? If everything is strategic, nothing is strategic. Every project is sold as strategic, making it nearly impossible to say no. Roadmaps drift with every new slide leading to partial implementations, abandoned platforms, and expensive sunk cost write-offs. and no stable target around which to organize goal enablement. 8. Roadmap A roadmap is too often a colorful Gantt chart or a list of projects with dates. In enterprise architecture and business architecture terms, a roadmap is a stage evolution of enterprise, business, and enterprise technology. beginning with an understanding of the desired and future state from the current state, explicitly showing how each step advances again. What goal enablement? Why is this costly? Programs are approved without understanding architectural prerequisites or their contribution to goals. So they hit invisible walls mid-flight and require costly rework. Parallel initiatives collide or overlap because there's no shared view. of how changes stack up toward goals and lead to double spend and even sometimes worse, and delayed time to value. Number nine is actually a duo. Framework versus certification. Many organizations quietly assume if we adapt a framework and send people to get certified, we must be doing architecture. A framework provides structure. Certification often proves that someone can pass an exam about that structure. Neither guarantees your enterprise is being deliberately designed for goals or actually doing architecture. This is why it costs money. You get the worst of both worlds, heavy process and vocabulary, but light connection to how the business makes or saves money. You hire or promote based on certification badges, then discover that certified staff cannot oversee complex cross-domain decisions. So you're a layer inexpensive consultants. on top of those, in quotes, certified architects. Passing a multiple choice exam has never made anyone a practicing architect. And number 10, governance. Governance often conjures up image of committees that slow everything down. Proper architectural governance is about design rights, decision rights, guardrails, feedback. that ensure changes really enable enterprise goals, manage risk and remain coherent with direction. As an engineering phrase exemplifies, an open loop system produces defects, a closed loop system produces quality. This is why it's costly. Governance is misunderstood as more approvals. Teams route around it. Unfortunately, you end up with shadow IT, fractured data, overlapping platforms, and no reliable way to see where changes are helping or hurting your goals. Governance becomes a cost center instead of a way to protect value. What do we suggest CIOs, CTOs, and responsible managers do this coming quarter? You don't need more jargon. You need a shared simple lens. Goal enablement. We suggest three concrete moves. Declare goal enablement the standard that is measuring what you're doing. publish a concise definition. Every significant change must show which enterprise goals it advances, what the enterprise must be able to do to reach those goals, and how the change strengthens those abilities. Change the questions in your forums and meetings. In steering committees and architecture reviews, stop at every major initiative and ask the following. Which goals does this enable? What specifically will we be able to do after this change that we cannot do now? How does this show up in outcomes and money? And invest in practice, not just certification badges. Fund the development of real goal enablement architecture certification, real architecture frameworks, real architecture methodologies, and real architecture practice. Examples, patterns, matter mentoring, and simple sets of views that the business and technology leaders can understand in one sitting. As we call it, human consumable business oriented. architecture and treat frameworks and certifications as tools and not proof that architecture is managed. Please reach out to us at the Enterprise Architecture Center of Excellence or the Business Architecture Center of Excellence www.eacewe.org or www.bacewe.org for a no-cost review and evaluation It would our pleasure to determine where you are and what you can do to go to the next level of enterprise and business architecture aligned gold enablement. We look forward to hearing from you.