A Compelling Enterprise Architecture Story: Chapter one

By Steve Force

Picture this scenario (fictional albeit representative):

Rebecca works at a global enterprise where she is a Senior Enterprise Architect. So today as Rebecca was walking through the hallway at work she ran into the CIO, Sabine, who told her in passing, “Walk with me a bit, Rebecca. I just got out of a leadership meeting where we were discussing our business capabilities and our ability to effectively transform our business as needed. There was a high degree of frustration in the group about how complete our knowledge of existing capabilities is, and how accurate the information that we base these capabilities on. Since I’m the CIO, they all looked to me for information. I assured them that the information given leadership by the enterprise architecture team is in fact accurate and is up to date. So, I really put myself on the line here, and I want assurances from you and your team that what I said to my peers in leadership is in fact true. “

She went on to say, “Rebecca, I know we provide them regular updates on the current state of architecture, as well as potential issues we might see going forward. I’m reasonably confident in these updates but I am not sure if the information we’re providing to leadership is truly being understood and how well it resonates.”

“Do we have a way to clearly illustrate our current capabilities and which systems support these? We need the information to be up-to-date and accurate”

Sabine added, “I want you and your team to critically examine the information that I take forward into leadership meetings and not only vet the accuracy of this information, but also if there are perhaps other ways to present this information that would resonate more.”

The CIO said, in parting “Thanks for your ear, Rebecca. Like always, we don’t have much time for this. please get back with me as soon as possible with this. I would like to have an update by close of business today, please.”

Sound familiar?

Rebecca keenly knows from previous discussions with leadership that a couple of key decision makers seem skeptical about Enterprise Architecture, saying the Enterprise Architecture group is too expensive and provides too little value.  So, she knows the pressure on her group to perform.

Rebecca knows that this is a great opportunity for the Enterprise Architecture group to really strut their stuff, to prove their value in a highly impactful way. The question is:

  • can they do it?
  • Are your Enterprise architecture artifacts this up-to-date and accurate? Do we really have an EA focus on capabilities? How do we keep these EA artifacts accurate? Do you we know?
  • Even though we use a well-regarded, commercially available EA tool, we cannot automatically assume that our architecture artifacts/diagrams/views are being updated. Many times, these are created during the early phases of an architectural initiative and are rarely, if ever updated.
  • Can they, in a short period of time and in a highly impactful way, communicate their message effectively?  

There certainly is a lot to consider.

This is the first of several articles I will be writing for this publication concerning what I consider some of the most important challenges and opportunities facing today’s enterprise architecture practitioners. This and all subsequent articles will be based on real world situations and on the experience of this author and the many resources we have available through his quest to better understand his long-term commitment two enterprise architecture success. These articles are intended to shed light on some of the more challenging aspects we faced today, with some examples and supporting documentation for us to successfully change as our discipline changes. Not only will we be looking at architecture as a practice, but also driving change through the organization through best practices and implementing and using modern IT methods and patterns and processes and then demonstrate these. In short, thought leadership. Communication is always first and foremost when it comes to architectural goals, and this is one of the hardest things to accomplish. So, we will look at some communications best practices and thoughts and then see how we could potentially implement them. Keeping enterprise architecture relevant is always a challenge to any organization regardless of size, maturity, length of time in business, and how the business formed. These articles will be for the most part technology agnostic, but when technology is needed I will stick with industry best practices and open-source examples from which one can either use open source, or vendor supported technologies which are based on open source.

I am a firm believer in being a hands-on EA practitioner. However, this is not to say all enterprise architects need to be hands on; rather, it pays in my opinion to have hands-on capability within the enterprise architecture team, which will be touched on later on in this article.

Trust, value, communicating, storytelling and selling and are key components of a successful Enterprise Architecture practice

By Steve Force

I am a firm believer selling is a key component of enterprise architecture. Why selling you might ask? Simple. If we cannot sell our ideas to the decision makers, what value are we truly adding to the organization? To me, trust, value, communicating, storytelling, and selling are key components of any successful enterprise architecture practice.

To me, the notion of selling within the Information Technology discipline is not new. In fact, for many years I have been a follower of Stephen Covey, Neil Rackham, Mahan Khalsa, and more recently, Raj Ramesh, to name a few.

  • Neil Rackham  – SPIN Selling (abbreviated to Situation, Problem, Implication, Need) – https://en.wikipedia.org/wiki/Neil_Rackham
    • “It’s important to be clear about your objectives when you approach people at the focus of receptivity. Calls to people who are purely receptive—which is a way of saying that they are not dissatisfied, and they don’t have decision power—tend to be most successful if your strategic aims are to find out information about the account and the people in it and to gain access to others in the account who are located at the focus of dissatisfaction.” 
      ― Neil Rackham, https://www.goodreads.com/work/quotes/782532
  • Raj Ramesh
    • How to Master the Art of Storytelling –  as described in this YouTube video. https://www.youtube.com/watch?v=357t2QLTVD4&list=RDCMUCbojg-FJgI1L6iLWUzgcsww&index=9

”Business architects research, understand, synthesize, and model a lot of information about business and technology. While these are critical, if we don’t communicate them well to our audiences, then the end result might be poor. So, communication and storytelling is a critical skill that we need to develop and learn. How do you tell craft compelling pieces? In this video, I share some of my experiences and what has worked for me. You might adapt some of these techniques but play to your strengths on what comes naturally to you to craft stories in your unique way.”

“The imperative of enhancing communication between business and IT stakeholders yields numerous practical suggestions conducive to the quality of decision-making in an EA practice and, eventually, to business and IT alignment. Even though these suggestions are very diverse and cover various aspects of an EA practice, the three major target areas include EA-related processes, documents and governance procedures. The respective suggestions can be best formulated as questions, answers to which should be sought by architects, all of which can be clearly traced to the common goal of improving communication.”

Why listen to me?

By Steve Force

Steve Force: a researcher, curator of information, a practitioner of Enterprise Architecture.

Although I believe I think with an open mind about many things—professional and otherwise—I would never call me an original thinker, or a seminal thinker. I firmly believe I am a researcher, a curator of information, a practitioner of Enterprise Architecture. I am no better, nor worse, than any one of you. I am just willing to admit perhaps I do not have the answer, but the answer is out there somewhere. The trick is to look AND gauge the potential answer for validity, for accuracy, for relevancy. This, in my opinion, is very difficult to do. It takes hard work, commitment, and the willingness to be humble.

I have been doing this thing we call I.T. for a while, and I have the bruises, scars, and experience to show for it. I know, everyone mentions their experience. Let me take this opportunity to actually go back into my archives to pull out a few tidbits of text I have published over the years.

I started writing and publishing articles way back in 1990, when I was living and working in Germany and Switzerland, while performing hands-on consulting on large-scale IBM MVS systems for large, global enterprises based in Germany and Switzerland. 

Here are some excerpts from some of these.  For a PDF of the complete article, please click the provided links following each excerpt.

Avoid, at all costs, repeating EA mistakes!

By Steve Force

As Enterprise Architecture researcher Svyatoslav Kotusev writes in his article, “Vicious and virtuous circles in enterprise architecture practice” (https://www.bcs.org/articles-opinion-and-research/vicious-and-virtuous-circles-in-enterprise-architecture-practice)

“The fate of enterprise architecture (EA) practices in many organizations historically has been bumpy and stormy”, writes Svyatoslav Kotusev, Enterprise Architecture researcher. He goes on to write, “Why do EA practices in some organizations run more or less steadily and productively, while in other companies they represent a long series of intermittent fiascos and relaunches, hopes and disappointments? “

Keep reinventing, remain relevant

By: Steve Force

According to Pierre Pureur, Murat Erde, and Eoin Woods in their 2021 book:

“Continuous architecture in practice” (Library of Congress Control Number: 2021933714, ISBN: 13:978-0-13-652356-7) “ https://continuousarchitecture.com

“The demands of modern software engineering mean that we need updated architecture practices that allow organizations to effectively manage complex, conflicting and cross-cutting concerns such as resilience, security, and technical coherence, and meet the fast-changing needs of complex groups of stakeholders.”

Having  hands-on EA capability is critical for EA success

By Steve Force

Having hands-on Enterprise Architecture capability in ones organization should not come as a surprise to EA practitioners.  According to Kevin Hickey, as published in the Architecture & Governance Magazine (September 6, 2019) “The Changing Role of the EA in an Increasingly Agile World, he writes:

“You are an Enterprise Architect in an organization learning agile practices, and you are feeling a bit lost. You have worked hard to get where you are. You probably wrote most of the critical system software keeping your enterprise running. You helped design the architecture. You know some of it is bit fragile, but with too few resources and too little time, compromises have to be made. In fact, your own ability to keep up with the latest trends have suffered because only you know how to keep things working. To help manage time, you have implemented universal standards and tried to funnel requests to architecture review boards or other planned meetings. Developers complain about all of the process, but you are just trying to keep control over the chaos that would certainly take over without it.

In an agile organization, good architecture is just as important as in a traditional enterprise. The role of the architect, however, is very different. The development teams have the freedom to make more impactful decisions, but also the responsibility to keep everything running. Heavyweight processes and centralized decision-making interfere with the short feedback loops required to make agile development successful. You have to adapt to this new environment by adjusting how you ensure that the chaos is held back and enabling the teams to make good decisions”

“To be successful, you focus on three key areas:

  1. Know the code
  2. Make the architecture visible to everyone
  3. Build bridges between teams”