The clock has started; the project funded. Now it is the time for Cea and her team to show the company their high value and ability to lead. Admittedly, this is a very daunting challenge, but it is one Cea was willing to take and make happen. After all, the future of the EA team was at stake.

The current team is uniquely qualified and ready to drive this initiative. Some, but not all, EA team members understood the value and importance of a successful implementation; not only for the organization, but also for the good of the enterprise architecture team going forward. However, others on the team, ones who don’t want a lot of additional process and are not yet convinced of the value of some touted EA best practices (such as TOGAF, etc.), were pushing back. After all, they prided themselves on their technical stills and didn’t see the reason to change their mindset, at least at this point. These individuals needed to see the value firsthand. Coming from a technical background herself, and still keeping a hand in it, Cea understands this position. This was a critical challenge; however, she knows the team engagement approach must change, and change quickly.

Limited funding, short runway

With funding just for six months, and only essential outside help (SME) permitted, resourcing this will be a challenge. Also, leadership reporting needs to be provided weekly, with tangible, measurable, meaningful goals presented.

Rebecca gets the nod

The Chief EA gets this critical initiative going by assigning it to Rebecca, an experienced senior architect on the EA team. This is precisely the opportunity Rebecca has been waiting for, as she knows the EA team can do a lot better than it currently is. She believes she has seen better, and is determined to do the job correctly and successfully. A lot is at stake here—pride, reputation, etc.

Why Rebecca?

Rebecca has been with the company for two years and is currently the lead EA on the infrastructure initiative. Her background with global IT technology service providers has been involved in implementing several complex initiatives, with varying degrees of success. She knows what has worked, what has not, and is determined not to repeat failing initiative steps as much as possible. However, she also knows failure is inevitable, and if handled correctly, can in fact help drive a successful initiative. Rebecca has internalized the expression “fail early, fail often” and is keen to showcase this ability here.

One of Rebecca’s previous employers prided themselves on being a CMMI level 5 (CMMI, n.d.) organization, which is a very difficult level of excellence to achieve.

To accomplish this high level of competency, the previous company required all key personnel to be trained in, and subsequently implement, industry standards such as TOGAF, BIZBOK, Six Sigma, ITIL, and others. Rebecca understood the value brought by these, even while seeing the flaws and conflicts between each as the organization implemented them into sustainable operational processes. It was not easy to do.

Cea also knew how important and critical this knowledge was to successful organizations. However, she also knew human nature fought against such implementation. Change is difficult, and anything considered a “standard” went against the grain of many who considered themselves “unique”, and also against the political walls inevitably found in organizations. No one wanted to give up power and prestige without a fight, or a push from management.

This is why Cea assigned the critical project initiative to her.

Rebecca hits the ground running

Initially, Rebecca brought in Progetto, an experienced Scrum Master as project coordinator. She knows Progetto will be valuable in keeping things organized and documented—but not to lead the initiative. Rebecca will be doing that. However, she plans for Progetto to take on more responsibilities as the project advances; after all, she already is an experienced Agile Scrum Master and knows how to run Agile teams. Rebecca is counting on Progetto and values her expertise.

Cea brings in Steve

They brought in a person whom Cea had worked with before, a practicing EA consultant who had trained Cea in TOGAF when she was at another global IT provider firm. Cea also knew he had a working POC that consisted of many of the identified requirements, as well as the rationale as to why this approach could be leveraged here. His name was Steve. He agreed and quickly joined the initiative.

Steve hit the road running, going from 0 to 70 in 5 seconds flat

Steve ramped up quickly, as he was highly experienced and used to entering initiatives under pressure. In fact, he thrived with such a challenge.

After meeting with fellow team members and understanding the gig, Steve set out framing some possible approaches.

The purpose of these articles and coming attractions

This is the second in a series of articles to clearly identify a usable scenario and a usable proof of concept one could use in their environment.

Not only will there be words to explain the scenario, the approach, and the solution, there will also be usable best practices freely available to use. This is my way of paying it forward, as it were. While the published solution will completely map these articles, it will not completely solve your problem.

These are intended to get you started with the notion of the approach to a data-driven enterprise architecture solution.  While I’m providing this information for FREE, this content is just the tip of the iceberg. There will be content, training, and more coming soon I’m excited to share with you.

Watch this space!

The message is clear—we need to become a data-driven organization

Prez just got back from a major consultancy sponsored executive conference where the key takeaway, at least for him, was making your organization a DATA-DRIVEN DECISION-MAKING one. Perhaps to some this seemed like the idea du jour, the currently in fashion idea, but not so for Prez. He had heard all of this before; from his peers, from his advisors, and from his management consultants. It just seemed to be a very complex undertaking, one fraught with risks and uncertainty.

Prez knew it was time to invest in a big data initiative tied to business transformation, but was unsure just how to do it. Being the president and CEO of the company, as well as a major shareholder, he had the power to make it happen. He also had the desire. But how best to approach it without a major corporate disruption? The company was doing very well. The employees seemed happy, and for the most part the shareholders were content. However, he knew this could easily change, especially if the company started losing market share to more in-tune competitors who always seemed to appear.

It was time to make it happen. Just how is the question.

Leadership wants a new direction

Prez gathered the leadership team together and pitched to them this: (from (Stobierski, 2019)

Data-driven decision-making is the process of using data to inform your decision-making process and validate a course of action before committing to it. Today’s largest and most successful organizations use data to their advantage when making high-impact business decisions. How exactly data can be incorporated into the decision-making process will depend on a number of factors, such as your business goals and the types and quality of data you have access to. Though data-driven decision-making has existed in business in one form or another for centuries, it’s a truly modern phenomenon.

Prez challenged his leadership team to:

1. Become a data-driven decision-making organization within one year
2. Use a modest, time constrained investment that shows immediate value
3. Avoid or mitigate risk
4. Pull through the organization as quickly, organically, and sustainably as possible

This was not a hard sell for Prez, as Rand in research and development, Sami in sales and marketing, and Fin in corporate finance all have been investigating Data Science, due to having direct reports keenly advocating for this as well.

However, the business department heads were not sure how this would affect or impact their departments. They needed to be convinced.

There is a shown interest within the organization and some pent-up demand as well. The question is, as a company, as Prez has postulated, what is the best approach for all of us?

Mission statement created

After a spirited discussion, leadership hammered out this mission statement:

Mission statement

To steer the company towards a data-driven decision-making operating model that makes highly reliable and validated information accessible to authorized consumers, with data integrity and accountability held and maintained at the most appropriate source. The company strives to be as technology and vendor neutral as possible, maximizing business value while leveraging industry best practices and standards, reducing operating cost while maintaining, or reducing overall headcount.

Now, how to make it happen? This is the 60-million-dollar question.

The Chief Enterprise Architect sees her chance

As the Chief Enterprise Architect, Cea had a seat on the leadership team. The challenge excited her, as her long-stated goal was to steer EA toward a more professional, predictable, value producing practice going forward.

After all, Cea is keenly aware several members of the leadership team aren’t happy with the current enterprise architecture initiative. The results are not up to date or in line with leadership expectations, whatever they might be. Besides, a good EA is EXPENSIVE. What truly is the value of EA? If there is a value, how is it measured?

The Chief EA approached leadership with a proposal: She wants the enterprise architecture team to take leadership on this data-driven initiative.

Leadership green lights the proposal, with conditions attached

Leadership is willing to invest, but only to a point. The team must show immediate, provable value and sustainable progress for subsequent support and investment. Also, leadership is clear—no increase in permanent headcount.

However, before giving the green light, Prez told Cea the EA team must produce a vision statement that clearly and concisely describes the initiative mission in a short paragraph—an elevator pitch as it were.

This is the vision statement Cea came up with and presented to Prez and the leadership team:

Our vision is to help realize the corporate mission statement objective of data-driven decision-making operating model of a sustainable process into the company’s core DNA by using the unique skills of the EA practice and proving, by a Proof of Concept (POC), how this can be accomplished with minimal financial investment, minimum risk, sustainable measured value, little outside expertise, and not increasing EA headcount.

The proposal was accepted and green lit, but only funded for six months. Now it is time for Cea’s team to make it happen. A daunting challenge, but one Cea was willing to take and make happen.

…

The purpose of these articles and coming attractions

This is the first in a series of articles to clearly identify a usable scenario and a usable proof of concept one could use in their environment.

Not only will there be words to explain the scenario, the approach, and the solution, there will also be usable best practices freely available to use. This is my way of paying it forward, as it were. While the published solution will completely map these articles, it will not completely solve your problem.

These are intended to get you started with the notion of the approach to a data-driven enterprise architecture solution.  While I’m providing this information for FREE, this content is just the tip of the iceberg. There will be content, training, and more coming soon I’m excited to share with you.

Watch this space!

References

(Stobierski, 2019) – Stobierski, Tim, https://online.hbs.edu/blog/post/data-driven-decision-making

Use Cases manifested into Artifacts (views, diagrams, etc) which can become useable patterns.

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)

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”