Post 1- The Devil within the EA Stack

While I was reading the article titled “Back to Basics- The Enterprise Architecture (EA) stack simplified”, it took me back a couple of years to when I was first introduced to EA and how simplified it was described and written. Later, during the TOGAF course which I had signed up for I came to realize that there is plenty of information flowing in and is required to be managed for each of the 4 main domains (Business, Data, Application and Technology). In addition, you have the information and data flowing in between the phases to ensure that you are aligned with your original scope of EA.

In the article, they had defined the EA stack in figure 1 in a descriptive easy layout to understand the context for each building block as well as showing the flow of information in between. This is by far the best descriptive architecture in a “simplified” way.

Figure (1): Source- https://dalbanger.wordpress.com/2014/01/20/back-to-basics-the-enterprise-architecture-ea-simplified/

In figure (2) below is another way of looking at each of the domains as described using the TOGAF framework which is a bit vague but gives a representation of the flow:

Figure (2): Source- https://pubs.opengroup.org/architecture/togaf8-doc/arch/chap03.html

Lastly, the figure 3 which was sourced from GARTNER, as you can see the framework uses a very high level of information of the EA stack:

Figure (3): Source- Gartner Research Brief. 2008. Gartner Clarifies the Definition of the Term ‘Enterprise Architecture.’

The point my post aims to make is that the EA stack is not a to-do list where architects simply define one domain and move on to the next. In a complex environment, defined information requires frequent verification and updates as needed. As simple as it looks the EA stack requires a team and based on my experience in the past couple of years in the field, to successfully run an EA program it will require a minimum of four architects for each to focus on their area of expertise and ensure the information is up to date for decision making purposes and investments. All the information defined need to fit to connect with the other domains appropriately to ensure value is delivered to the stakeholders or in most cases to the C-Suite management to continuity receiving their support (I will the management support context for another post because I believe it is critical for the success)

Lastly, I wanted to emphasize how to approach the stack, this will be based on the organization’s current state and the key is defining the maturity level for each level. Also, as seen in all frameworks, it is always a good starting point to begin with business layer. This will lay out the organization’s blueprint for architects to make sure they support making the right investments.

Post 2- Bots are not for everyone

As I was reading through the Hype Cycle for Application Architecture and Development article from GARTNER and reading about the different solution enablers in the hype cycle, one solution that I recalled a lot of discussion and engagement work around the same time the article was written which was in mid-year 2020. At the time I had only joined the organization a couple of months ago and kept hearing about a lot of engagements about reaching the GO-LIVE phase of the chatbots. This was going on for months until it finally saw the “Soft launch” of the service by the end of 2020; however, it never made it past that phase and the project was killed off for many reasons but mainly management didn’t see the value solution that served 2-3 people each day.

For such projects to be successful, there must be a fulfillment requirement check list prior to considering and budgeting for it. Although it was at the peak of the hype cycle (see figure 1 below), this is a solution which can be classified as a nice to have capability and if not implemented to deliver a specific benefit can turn into a bottleneck for the users.

I want to share my high-level analysis of why the solution never successfully launched:

1. Lack of POC- I’m a big believer of POCs especially in such projects where the value expected is what the value is being received. Reference implementation can be supportive; however, since the organization is unique in its business operations, you can’t rely only on references. This was highlighted as advice, and I believe it to be true and should have been in place but wasn’t.
2. The narrow scope covers very specific services which only received 3 request/inquiries and on a good day only received 5. The business requirements gathered weren’t in the right place, perhaps the solution implementation would have been successful if it was for external users instead.

I had asked around about the project to get some insight from technical perspective and did a short interview engagement with person X to get some insight and lessons learned after the chatbot project was shut down. The interviewee responded to say that the root cause of the project failure was due to the following two main reasons:

1. Project/Initiative Ownership- The project since initiation didn’t have official ownership to it; although, the IT team oversaw the implementation, but it didn’t have a business owner. This caused a continuous bottleneck due to the nature of the project, data had to be continuously fed to the database to raise the level of accuracy in the “bot” response.
2. Corporate Culture- Resistance to fancy tools within the organizations. The organization has a very stringent culture and has low tolerance for inaccuracy of any information which the “bot” may respond. As I have mentioned in point #1, since there was no ownership of the project, no one wanted to take the responsibility of the information or responses the “bot” might provide users.