How can we, as Enterprise Architects, be the change we seek?

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/

Is how we think about the structure of the enterprise architecture stack changing?

Are digital disruption and the influence of cloud technologies fundamentally shifting how we think and communicate about the structure of the enterprise architecture stack?

In Enterprise Software Architecture: A Network of Services, Not a Layered Stake (2012), author Larry Hawes paints a picture of the future (and now current state) of the enterprise architecture as network architecture of service nodes that can be combined to address specific use cases. His central argument is that the way we traditionally think of an enterprise architecture is in layers (i.e. presentation, service, business, data, persistence) is fundamentally hierarchical and that this way of thinking is no longer valuable or representative of reality. That the introduction or adoption of cloud technologies has caused these layers to collapse on themselves an is resulting in the elimination middleware and a shift from prevailing enterprise software and integration design patterns. Instead, he urges “we should think in networked business terms and treat software functionality like networked nodes that may be fluently, even dynamically, related to each other” (Hawes, 2012).

I agree with Hawes that there is a fundamental shift in the way that we must think about the structure of the enterprise architecture, but in the near term organizations have been left with a tangled web technologies, and if IT departs don’t are able to responds quickly enough to demand then business units will move to bypass IT (and EA) and adopt Shadow IT solutions (Boulton, 2017). My point is, as with any disruptive trend, a new set of problems will emerge that need to be addressed. A simple example of this, that we can probably all relate to, would be how organizations responded to increasing demands to allow smartphones to be added to the network and used for both personal and work-related tasks. The bring your own device (BYOD) trend required solutions in the form of both policy and technology changes to manage and enable this solution for employees.

So yes, we need to start thinking about the enterprise and technology architecture in a very different way in order to begin to manage the disruptive influence of cloud technologies, but we still a long way from away seeing how this emerging ‘network architecture’ will be more efficient, flexible and less expensive (Hawes, 2012). In fact, would say the first wave of cloud adoption has led to increasing inefficiencies, less flexible 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 (Grainger, 2018). However, I am excited and optimistic about what solutions will emerge.

Sources:

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/

Boulton, C. (2017, December 08). Shadow IT: How today’s CIOs grapple with unsanctioned tech. Retrieved from https://www.cio.com/article/3240987/it-strategy/shadow-it-real-world-stories-of-unsanctioned-tech.html

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