Steve’s Practical Approach to Data-Driven Enterprise Architecture

By Steve Force

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

As mentioned in a previous blog post, I am a firm believer in a disciplined enterprise architecture approach that is 100% in line with business needs both present and future, while using established best practices in the choicest way possible, approaching enterprise development transformation in a powerful and transparent way.


I’ve mentioned before that being a creative guy myself, I know how the best thoughts evolve and are developed. There’s the seminal thinking and the germination of good ideas, which rarely, if ever, come from a structured approach. Creative, motivated people just dive in and start playing. They develop, then start the cycle of testing and breaking and testing and breaking until something works and is feasible. Then, there is a prototype that can be demonstrated in real time so others can grasp what can be done. Once this happens, the ship has sailed. The interest is there, and with this interest and excitement comes support (and funding) but oftentimes with little appetite to document the now 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 individuals to document 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 elements might seem rather straight-forward; however, how do you know where to find it and what data is needed? This is where I come in.

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

 then, I fully embraced long-held ideas 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 ideas evolve and execute within organizations.

This method allows me to use my experience in a way where I can fully embrace how developers like to develop and evolve their systems. It also lets me meet the needs of leadership business owners and key stakeholders, as well as the classical IT management, operations, enterprise architects solutions architects developments staff, and others. I can automate through a data driven machine, learning analytics and the big data system that clearly demonstrates how modern enterprise architecture can be accomplished without blowing up, disrespecting, or making obsolete the current industry best practices.

What I do is focus on the middle: change, working with the process owners in the narrative, visuals, and data, and collaborating with stakeholders on the tasks of explaining, engaging, and helping enlighten all stakeholders.

I do this by understanding the requirements and expectations of the various stakeholders and anticipating their needs. I’m constantly looking for patterns, using 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 I DELIVER.


Experience, Knowledge, Patterns and Best Practices

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

It also tries to anticipate a customer’s EA needs before they are even aware of them, utilizing a proactive and prescriptive approach.

Practicing Enterprise Architects should have both immediately usable and applicable knowledge about current best practices and trends to better serve the customer. My personalized approach reflects this.

This, to me, means using Data Science/Big Data.

Enterprise Architects should not be technology or vendor aligned, and our approach to a situation should be as neutral 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 won’t consider another approach; to the contrary, I practice my discipline in the way that makes the most sense, and hopefully provides the most immediate value to my customers.


How? Patterns and Process

How do I approach the customer’s need? Simple: by using established patterns and processes like: 

  1. TOGAF
  2. ITIL 4
  3. As technology/vendor independent as possible
  4. Data science/big data
  5. Knowing/discovering where data elements are (source of truth)
  6. Utilize Open-Source technology such as:
    1. ElasticSearch
    2. Kibana
    3. Logstash
    4. ArchiMate
  7. Leverage patterns and code I have developed to harvest pertinent data elements
  8. Make use of patterns and processes I created to place those relevant into EA artifacts needed for current and future use
  9. Anticipating customer EA needs before they are even aware of them, taking a proactive and prescriptive approach
  10.  Implementing thought leadership
  11.  Executing technology leadership for and/or and creating proof of concepts (POC) for high-impact enterprise-level technology initiatives

By using this multi-step approach, customers are given a personalized experience to meet their individual needs, while receiving data driven results. These methods not only provide a solid outcome, but allow for their critical service needs to be met efficiently and exactly. 

(updated Nov 30, 2021)


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”

A Walk down Memory Lane.

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 IT for awhile, 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, starting in late 1990 through 2004.

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


  • In May 1994, I wrote an article forCrain’s Detroit Weekly that they opted to publish. Entitled “Info-systems Investments will pay off”, I used Dick Tracy as an analogy. Remember, I wrote this article several years before the advent of ubiquitous hand-held data-communications cell phones, Wi-Fi, etc. Here is an excerpt of what I think is an interesting, informational article:

“Is it productive to attend a meeting and not have what is needed immediately available? Why should someone spend time preparing for a meeting or presentation when the data can be accessed dynamically?

https://steveforce.com/1994/05/13/crains-detroit-weekly-article-info-systems-investments-will-pay-off/


  • In February 1994, I wrote an article entitled “Strategic Skills for 1994: A Technical Support Top 10 List” which played off of David Letterman’s late night TV show’s “Top 10”, which were popular at that time. Here is an excerpt of that article, the “list”:

“Here are some skills that I feel are strategic, sort of a “Technical Support Top 10 List.” This list is not all encompassing but is certainly food for thought. David Letterman’s lists are more entertaining, but the items in this list might help keep food on your table.

1. Know why the enterprise computer center is and will remain a corporate asset.

2. Learn all you can about “open systems” and how they can be realistically implemented.

3. Know what products your shop currently has installed, what these products can do and how they can be exploited for use in an “open system” environment. MVS has several inherent “open system” functions, as well as some exciting near-future products (e.g., Open/MVS). Other products might include: TCP /IP, NFS, LANRES, ADSM, etc. (all mentioned products have been previously discussed in articles by myself and fellow .. authors).

4. Become familiar with current “hot” systems like NetWare, Windows NT, OS/2 and Unix. If any are installed in your enterprise, personally get to know the techies responsible for each.

5. Become “connectivity literate” by becoming familiar with TCP /IP, IPX-SPX, SNA in an heterogenous networking environment, as well as learn how to connect disparate systems to SNA.

6. Learn about the Open Software Foundation (OSF) Distributed Computing Environment (DCE). I have found Rosenberry, Kenney and Fisher’s Understanding DCE (O’Reilly and Associates, Inc.) to be a valuable DCE learning and reference book.

7. Become conversant in object-orientated programming (C++, Smalltalk, etc.).

8.Be able to effectively sell your “open system” ideas (based upon your deep and broad knowledge of the total enterprise computing environment) to upper management.

9. Open your mind to other people’s technical enthusiasms and ideas. MVS is good, but it is not the “greatest.” Nor is VM, VSE, Microsoft Windows, UNIX, OS/2, NetWare, etc. All of these operating systems have their place in an enterprise.

10. Lastly, always remember no solution is perfect. No operating system and networking scheme is perfect, either. Leave the debate for “the perfect system” to the academics and the hobbyists. Accept industry trends at face value and get on with it.”

https://steveforce.com/1994/02/14/forcesight-column-feb-1994/


  • In June 1994, I wrote an article which attempted to compare IT needs of small and large firms, entitled “Comparing the IS needs of Small Firms and Large Companies”. Here is an excerpt of that article:

Whether your firm is a large corporation or a small business, there are two ways to satisfy your IS needs, either through in-house developed or outsourced products, or purchased package customization.”

https://steveforce.com/1994/06/14/forcesight-column-june-1994/


  • Here is a fun article I wrote back in December 1993, entitled “Music to My Ears”. Here is the opening paragraph excerpt:

“This month I thought I would write about a subject that I find very interesting and that applies to computer techies like us: electronic music. It is applicable because in the future, chances are we will be getting more heavily involved with multimedia and teleconferencing within the enterprise.”

https://steveforce.com/1993/12/13/idr-forcesight-column-dec-93/


  • In a different vein, here is an article I wrote in July 2004 entitled “What is Portfolio Management and why should IT care?” Here again is an excerpt:

“ How does a company know if they’re working on the right IT projects? How can they tell? Why do managers often make questionable IT investment decisions? Why don’t they know what technology is worth to the business?”

https://steveforce.com/2004/07/13/bij-what-is-portfolio-management-and-why-should-it-care-july-2004/


What a fun trip down memory lane! At least it was for me. Although the technologies might have changed, the fundamental need for good architecture and pertinent, timely architectural reports, diagrams, and artifacts haven’t.  

Thanks for reading!

My Thoughts on Applied Enterprise Architecture

By Steve Force

As a Data-driven hands-on Enterprise Architect (EA) practitioner it concerns me how often we must justify our value to the organization.

As I think back over my long Information Technology (IT) career, I find it interesting that I can still apply my university-level computer science core course learnings; the content, the discipline, and even the approach hasn’t really changed that much. We still think data structures, patterns, procedures, functions, objects, etc. just like we did almost forty five years ago.

The more things change, the more things stay the same?

Like many of you, I have come up through the IT ranks, starting as a computer operator, then moving into:

  • IBM 370 systems programmer,
  • Enterprise capacity planner,
  • Large scale system integrations /transformations,
  • IT technical consulting,
  • IT management,
  • Certified technical trainer,
  • Certified project manager (PMP),
  • IT change processes (ITIL, for example),
  • Technical Architecture, and
  • Enterprise Architecture.

Along the way, I have also shared my thoughts and experiences about Information Technology, at https://steveforce.com. These articles go back over 30 years, illustrating my deep commitment to our discipline.

While this has been a great career, and I’ve both learned and seen a lot, often it seems like I’m chasing something that might not ever be achievable. At times, I think the (IT) discipline isn’t maturing in a way I think it should be.

I KEEP HEARING THE SAME THING OVER AND OVER WHEN PEOPLE DESCRIBE EA – or, it perhaps it seems we EA practitioners are simply spinning our wheels!

But maybe it isn’t that the IT discipline isn’t maturing. Instead, maybe my way of thinking about this is flawed. Maybe I should rethink my approach, and rather than trying to place my thinking as archetype in the situation, take the realities of common practice and tailor my approach to best serve the needs of IT.

I am a firm believer in a disciplined approach that is 100% in line with both current and future business needs, while still using the established practices in the best way possible to approach enterprise development transformation in a powerful, transparent way. However, being a creative guy myself, I also know how the best thoughts evolve and are developed. The seminal thinking and the germination of good ideas rarely, if ever, comes from a structured approach. Instead, you just dive in and start playing and developing, then testing and breaking and testing and breaking until you have something that works and is feasible. The result is a prototype that can be demonstrated so others grasp what can be done.

Not only is this fun, but it’s fast and quickly iterable. It completely supports the notion of fail fast, fail early, fail often, and continuous development, continuous integration.

As a classically trained Enterprise Architect practitioner, I’ve tried to drive from a top-down approach, meaning leveraging classical enterprise architecture practices. I also embrace the bottom-up and in the middle-in approaches; however, my success rate seems to be mixed.

I don’t think it’s a matter of me not doing well. I oftentimes just can’t demonstrate value using my approach.


I think it’s high time to blow up my thinking..

I think it’s high time to blow up my thinking  and fully embrace the long-held ideas I’ve been nurturing for many years of developing and manifesting 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 ideas evolve and are executed within organizations.

I remain rooted in both Enterprise Architecture AND as a Hands-on practitioner

Using my experience in a way where I can fully embrace the method developers create and evolve their systems allows me to meet the needs of leadership business owners and key stakeholders, as well as classical IT management, operations, enterprise architect’s solutions, developments staff, and others. I can automate through a data driven machine, while learning analytics that can clearly demonstrate how modern enterprise architecture can be accomplished without blowing up, 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, and by collaborating in explaining and engaging, helping to enlighten all stakeholders.

This is done 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 and the goal of being a truly data-driven ecosystem, AND THEN DELIVERING.


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

Click on Steve’s approach to Data-Driven Enterprise Architecture. click: https://steveforce.com/2021/11/23/steves-practical-approach-to-data-driven-enterprise-architecture-2/

(updated November 29, 2021)