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.

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

• Mahan Khalsa –“Let’s get real or let’s not play.”
  • “Stephen Covey’s sixth habit of highly successful people, “Seek first to understand—then to be understood,” applies to highly successful business developers.” 
    ― Mahan Khalsa, Let’s Get Real or Let’s Not Play: Transforming the Buyer/Seller Relationship

• 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.”

• Svyatoslav Kotusev – Enterprise Architecture researcher Svyatoslav Kotusev wrote, in his October 5, 2020 article “Enterprise Architecture: Forget systems thinking, improve communication” article  – https://www.bcs.org/articles-opinion-and-research/enterprise-architecture-forget-systems-thinking-improve-communication/

“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.”

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.

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? “

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.”

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”

How to deliver? This is what my practice area is all about.

Steve’s practical approach to Data-Driven Enterprise Architecture

(see precursor, thoughts on Applied EA for context)

As mentioned in (previous blog (reference link.)), I am a firm believer in a disciplined enterprise architecture approach that is 100% in line with business needs both current and future, using the established best practices to the best way possible to approach enterprise development in transformation in a very powerful transparent way.

Also as mentioned in ((previous blog (reference link.)), being a creative guy myself, I know how the best thoughts evolve and are developed, the seminal thinking and the germination of good ideas, rarely if ever come from a structured approach.  Creative, motivated people just dive in and start playing, developing, and testing and breaking and testing and breaking until you have something that is working and is feasible. You then have a prototype that you can demonstrate in real time so that people can grasp what can be done. Once this happens, the ship has sailed. The interest is there, and with this interest/excitement comes support (and funding) and oftentimes with little appetite in documenting the already developed logic, nor any real interest in documenting future logic.  

And what about Enterprise Architecture documentation/artifacts?

This is where my approach comes in.

Rather than trying to get busy, engaged, and focused people to documents their work in progress or past efforts, why not just grab pertinent data from their source? Sounds easy and straight-forward, doesn’t it?

Well, yes and no. Getting access to pertinent data element might be rather straight-forward; however, how do you know where and what data are needed? This is where I come in.

I blew up my pre-conceived ideas about my EA Practice….

…, or rather, fully embrace my long-held ideas which I’ve been nurturing for many years now of developing and manifesting the notion of an agile enterprise architecture or a perpetual enterprise architecture or a continuous enterprise architecture or what I now call a “Data-driven Enterprise Architecture” by thinking about how within organizations ideas evolve and execute.

By using my experience in a way that I can fully embrace the way the developers like to develop and to evolve their systems, fully embrace the needs of leadership business owners and key stakeholders, as well as the classical IT management , operations, enterprise architects solutions architects developments staff , etc., I can automate through a data driven machine learning analytics big data System that can clearly demonstrate how modern enterprise architecture can be accomplished without blowing up or disrespecting or making obsolete current industry best practices.

I focus on the middle: change, working with the process owners in the narrative, visuals, and data, by collaborating with said stakeholders on explaining, engaging, and by helping to enlighten all stakeholders.

I do this by understanding the requirements and expectations of the various stakeholders, anticipating their needs, constantly looking for patterns, best practices, data sources etc., that can be leveraged via data science best practices with the goal being a truly Data-Driven ecosystem, AND THEN DELIVER.

EXPERIENCE, KNOWLEDGE, PATTERNS and BEST PRACTICES

My approach is a minimal disruptive/high impact approach, keeping an eagle eye on cost while maximizing results with potentially multi-factor benefits.

It also tries to anticipate customer EA needs before they are even aware of these needs (proactive, prescriptive approach).

My thinking here is since, in my opinion, practicing Enterprise Architects should have immediately usable and applicable knowledge about current best practices/trends, my approach will reflect this.

This to me means Data Science/Big Data.

Also, enterprise architects should not be technology or vendor aligned, so, again in my opinion, our approach should be as neural as possible. This means to me, Open-Source.

So, my approach leverages Open-Source technologies as much as possible. Now, this does not mean I will not consider another approach; to the contrary, I practice my discipline in the way that makes most sense, and hopefully provides the most immediate value, to my customers.

How? Patterns and Process

How do I approach this? I use as often as I can established patterns and processes. 

(idea.)

1. TOGAF
2. ITIL 4
3. Open source if possible
4. As technology/vendor independent as possible
5. Data science/big data
6. Knowing/discovering where data elements are (source of truth)
7. Anticipating customer EA needs before they are even aware of these needs (proactive, prescriptive approach)
8. Leveraging Open-source technology:
   1. Elasticsearch
   1. Kubana
   1. Logstash
   1. ArchiMate
   1. Etc.
9. Leverage patterns and code I have already developed to harvest pertinent data elements
10. Leverage patterns and process I have already developed to place these pertinent into EA artifacts needed for current (and future) use.
11.  

Steve Force is a veteran IT Enterprise Architect practitioner that has done many of the IT jobs there are and for the past few years has specialized on applied Enterprise Architecture (EA). This means you don’t have to explain much to him—he has been there. Steve can help you by immediately turning your thoughts/vision/requirements into real EA artifacts you can immediately use. He can do this because he has the patterns and support pattern logic in his tool kit ready to use.

Steve is completely hands-on, working daily with docker containers, Python, Elasticsearch, Kibana, ELK Painless, Github/gitlab, patterns, Vega Visualization, Archimate, AWS, Microsoft Azure, and Google Cloud Platform, to name a few.

Don’t believe me? Try Steve’s toolkit for yourself – he is making some of it freely available to the open-source community—paying it back and forward as it were.

He is very selective on who he works with, giving these clients his complete attention in a very personalized, yet cost effective way.

Steve Force is highly cost effective, as you pay for his 40-plus years of experience and demonstrated results, not him learning on your dime.

Using a master mechanic analogy, he knows which screw to turn, which parameter to tweak, to diagnose quickly.

Check him out!