I wanted to dive into the maturity models and attempt to identify some of the challenges inherent around the changing landscape of IT and EA. These disruptive shifts in the way assets are built, acquired and managed within the organization are becoming a challenge to the organization to successfully implement. Namely these shifts are DevOps, Cloud and Agile (referred to as the “shifts”). The combination promises deep savings in costs, high productivity against innovation, manageable and fungible assets through software defined virtual assets. While I do see the value in these shifts, I also still see the need for Enterprise Architecture, just not in the form that it’s in today. The following commentary on the maturity models and challenges are only based on experience and opinion.
Below are the 4 stages of maturity that is called out in the reading [1]. These are as follows:
1) Business Silos
2) Standardized Technologies
3) Optimized Core
4) Business Modularity
Starting with first state, whereas Business Silos are the norm. Each business manages themselves in their own fiefdom, from HR to Technologies. A company that is in this stage is most likely just standing up an enterprise architecture practice. Consequently when these three disruptive technologies are embraced by an organization in the first level of maturity, EA’s challenges would be getting the practice off the ground. This would be exceptionally difficult due to the main premise being that EA is a cost control and saving measure. While this could be debatable, the complexities that a large scale dev-ops system for each line of business would not only increase costs exponentially fro the implementation, but kick off large scale migrations to shoehorn things into the pipeline. Resources would be thin, and pressure on the newly formed EA group would be beyond their capability to meet the needs of the changing organization. I would guess that the promise that the shifts will bring would far outweigh anything that Enterprise Architecture could deliver.
Introducing these shifts during a companies standardization phase of EA maturity would prove out similarly in that the cost reduction wouldn’t be a huge factor, especially if the embrace of open source was central to the organizational goals. Digital assets, would be acquired and built only to find themselves running in an on demand scenario in the cloud. Standardization would most likely seem to be restrictive, effectively stymieing innovation. There is so much available to the agile developer, introducing command and control would then box the developer in on technologies and potentially also destroy productivity. The job of EA as the shift becomes pervasive would become increasingly difficult as they would be searching for the value beyond business and processes for realizing the ROI of projects. Areas like data and technology architecture would have trouble keeping up with the sheer scale of what’s out there. The business end of EA would almost have to take on justifying their architectures through some sort of financial modeling.
The third level of maturity speaks to “Optimizing the Core” of the business. This presupposes that their are core processes and systems in place that are shared between the business lines. The migration to the cloud would pose a problem in itself when looking to roll-up costs to a line of business. Few initiatives can take into account the limited bandwidth that is introduced as EA corrals enterprise services. Changes to shared services and/or processes requires more time and effort across the enterprise. This is a risky move for EA when the tendency is to move fast without cross-enterprise contention. This is truly where the organizational structure would see changes at a high level. The leaders would have to agree across the enterprise in project priority and resource scheduling. This is problematic in the agile world. The introduction of DevOps would best aide in supporting the centralized systems but without clear ownership and service contracts being create between teams the job of EA would fall less on the technology and more in project and process management. Arguably these complimentary disciplines are inclusive to themselves but EA has the ability to also influence change not only from the bottom up but top down.
Finally when the business modularity is achieved, the job of the Architect in the new landscape would change holistically, shedding some of the technical and data capabilities falling back on the process and business architects. These are the only things that really matter at the point of modularity. This is a mature and optimized state of the enterprise and these shifts that are introduced, beget traditional EA. The business and process architecture is still very applicable because these are areas that remain relatively unaffected by technology changes such as software defined networks.
The changes to the way that projects and ultimately delivery of value to the enterprise through initiatives is changing at a high rate. Enterprise architecture is still in need of change and guidance on how to help organizations weather the storm as these disruptive practices and technologies permeate industry. My opinion is that it will be less about the technology in the future as technology take more steps towards homogenization but the need for lean processes and clear articulation of enterprise risk and value will still remain relevant. Diligence in these areas of Enterprise architecture could then be strengthened with deeper concentrations in LEAN, Six Sigma and CRM. Additionally, the need for Enterprise Architects to embrace finances and start using it to drive value in the chains that are affected.
[1] Enterprise Architecture as Strategy, Jeanne Ross, Peter Well, David C. Robertson, August 2006
Views: 2
Thank you for the post. I was recently reading a book called "Lean Enterprise" by Jez Hubble, etal. He specifically talks about this issue of command and control of larger organizations and how it often impedes results that are readily gained by smaller organizations.
I agree with you that EA is still needed in the context of the shifts in IT to cloud and more abstracted virualized services.
One area that we are seeing a need is in the porting of applications from on-prem network to the cloud. Our "future-state" of applications is often regarding the effort to refactor to achieve the benefits of what cloud offers–for instance converting an application to run in Docker containers.
Interestingly, the amount of EA/governance that exists surfaces immediately..for better or worst.
Thanks again
Hi Joe, thanks for the comments. I agree that smaller businesses have more agility, however some of the bigger ones, if a paradigm shift is embraced the organization will change. I often head of a Harvard principle that basically is summed up with the image of a pendulum. Overcorrecting for each major change that is to be implemented. Change is the met full force by the org and correcting measures are put in play thought management edicts.
I would say the most mature organization was Bank of America. They have a very clear command and control structure and are able to meet the market changes by standing up divisions that rival their entire competitors footprint. As an EA, the most mature is my current position with another large bank. The EA group has evolved into something that worked fairly well, but is now going through changes that undercut the value of EA. It's honestly a frightening time, but on the flip side re-inventing ourselves and EA poses an interesting challenge.
I'm not sure I answered your question, but yes we've reached the proverbial Self-Actualization of EA. The changes and challenges are Cloud, Agile, SAFe, Federation and BigData. These all change the way we work as a company, driving innovation at a blistering pace but consequently challenging the need for Enterprise Architecture.
What is your background and experience within mature companies levering EA? I'm curious about your take on it all.
Michael,
Thank you for your post. The explanation on the different level of maturity worked well for me. Your thoughts on the risk associated with level 3 rings true to me as well. In these reading I have often thought how much organizational change would be necessary in the most mature organizations. Can an organization really change that much to become that mature in their use of EA? I tend to think that a small growing organization might have a better chance of evolving into a very mature level of EA better than a more established organization can change itself into this higher level of maturity. I don't know but your comments really seem to speak to this fact. What is the most mature organization you have seen or been a part of?
Thanks again for your post.