In Change as Core Competency: Transforming the Role of the EA, Jason Bloomberg (2016) alerts that EA must transform itself into ‘agile architecture’ in order to drive digital transformation. His view, like Hawes (2012), is that of the enterprise as a complex adaptive system with emergent properties, that is properties that emerge from the interaction of the different components that comprise the system itself. Agility, efficiency, effectiveness, and resiliency are all examples of emergent properties, but Bloomberg sees agility as critical property and change-ability as a core-competency for organizations to develop; however, unlike Kotter’s archetype of the change agent where “a single individual or small group of individuals are responsible for driving change in a previously static organization” (Bloomberg, 2016), the goal should be focused on helping the organization to better respond and adapt to the forces change. The implication for EA is that we must dispel the myth of the future state, and instead focus on making the current state better. That enterprise architects must become ‘architects of change’, by focusing on what is required to enable or realize it or to better leverage change for competitive advantage.
So what does Bloomberg mean by ‘agile architecture’ or ‘architects of change’? In a previous article, Is Enterprise Architecture Completely Broken? (2012), he states that “the writing is on the wall. For all the Miltons in the role of Enterprise Architect, applying frameworks and creating artifacts and generating documentation, the business value they provide is questionable at best”. He continues, “those EAs who truly embrace change – who work directly with business stakeholders to move their organizations to an increasingly agile state of continuous business transformation – will more likely find themselves adding real value to their enterprises”. Sounds great, but specifically how can EA add value? In part, I think the answer lies in the second wave of cloud adoption that has already started to shift the way of thinking and to bring to market new tools to help manage the tangled web of technology that resulted from the first wave (Grainger, 2018). I will save that discussion for later. First I would like to address this question: How EA can be agile?
“In one physical model of the universe, the shortest distance between to points is a straight line, in the opposite direction.” – Ty Webb (Caddyshack)
Somewhat ironically, Michelle Parsons (2018) argues that “agile is not the answer to all of your company’s problems. Silo busting is.” According to Parsons, efforts to implement agile in organizations are great, but doing agile does not mean the company as a whole is (capital ‘A’) Agile. Nor does it mean the company is effectively delivering business value to customers. Her line of thinking is this: “Agile vs. waterfall isn’t the issue, it’s communication across the organization. Silo busting is the key ingredient to successfully getting stuff done”.
Parsons makes several recommendations on how to approach silo busting, but I want to focus on one, in particular, that is having a single, prioritized enterprise backlog. “Why is this important?”, she asks, because “If you don’t establish a priority, people will make one up”. The perhaps more subtle point here is that the enterprise backlog is itself valuable, but it is the act of creating the backlog that provides the real value, by forcing the communication and collaboration between the business, finance, IT, program management, and the other verticals that must all come to consensus on the direction an priorities of the organization. (Note: This also has implications for how EA can better serve agile development practices.) In this example, vertical silos are the root cause of inefficiencies, lack of flexibility and high costs, and this is especially the case for services-based industries that are highly dependent on business processes that require collaboration across multiple business units (Richards, 2017); however, there is also benefit from busting the silos of people and technology that have formed around the technology stack. In Part III, I discuss how cloud technologies like micro-services are influencing the technology stack. To be continued.
Sources:
Bloomberg, J. (2016, June 16). Change As Core Competency: Transforming The Role Of The Enterprise Architect. Retrieved from https://www.forbes.com/sites/jasonbloomberg/2016/06/16/change-as-core-competency-transforming-the-role-of-the-enterprise-architect/
Hawes, L. (2012, March 15). Enterprise Software Architecture: A Network of Services, Not a Layered Stack. Retrieved from https://www.forbes.com/sites/larryhawes/2012/03/14/enterprise-software-architecture-a-network-of-services-not-a-layered-stack/
Bloomberg, J. (2014, July 11). Is Enterprise Architecture Completely Broken? Retrieved from https://www.forbes.com/sites/jasonbloomberg/2014/07/11/is-enterprise-architecture-completely-broken/
Grainger, R., & IDG Contributor Network. (2018, January 04). 3 steps to building a services-centric tech stack. Retrieved from https://www.cio.com/article/3245805/it-strategy/3-steps-to-building-a-services-centric-tech-stack.html
Parsons, M. (2018, August 8). Forget about Agile vs. Waterfall, Its About Silo Busting … Retrieved from https://www.linkedin.com/pulse/forget-agile-vs-waterfall-its-silo-busting-michelle-parsons/