Last week I talked about how digital disruption and the influence of cloud technologies fundamentally shifting how we think and communicate about the structure of the enterprise architecture stack. This week I would like to expand that conversation to discuss what impact this has had on the structure of the EA team. In Application Architecture Overview (Parts I – III), analysts Mike Blechar and Bruce Robertson lay out some of the key differences in the roles of Enterprise Architect, Solution Architect and Application Architect. The central differences seemed to parallel the common architecture viewpoints, that is, the enterprise architect role tends to focus on more conceptual deliverables, whereas the solution architect role focuses more on logical deliverables (in the context of the particular project), and the application architect focuses on the implementation.
My company employees a similar structure to the architecture team. At first scan, this could seem to be overly complex and bureaucratic, and that is the risk; however, the value of this structure becomes evident when you view this as not a hierarchy but of a network of contributors each adding their perspective to the overall enterprise architecture. Most notably, it is through the solution architect that the enterprise solution architecture (i.e. vision, standards, and principles) are applied to a specific project/problem context. At this more detailed or logical level of design, the SA’s role “includes designing and reusing software service and interfaces, which improves developer productivity and application agility, quality and consistency” (Blechar & Robertson, 2010), but the real value that the Solution Architect provides is ‘Silo Busting’. Furthermore, leveraging the SA role in this way seeds the enterprise mindset throughout the organization promotes the vision, and allows adaptation of new standards and technologies to quickly scale while allowing ownership of the ‘boxes’ to remain with the application owners.
In a previous post, I discussed what it means to be an agile enterprise. Michelle Parsons (2018) argues that “agile is not the answer to all of your company’s problems. Silo busting is”. Her line of thinking is that communication across the organization or silo busting is the key ingredient to organizational agility and getting things done. Solution architects focus on the lines between the boxes – both organizational and system boxes. It is the solution architect’s role to foster collaboration between business silos, and more and more this is manifesting itself in the technologies themselves. Technologies such as General Automation Platforms (GAP) or are emerging to help manage the ‘lines’ between organizational units and the supporting applications. A General Automation Platform (GAP) or Robotic Process Automation (RPA) is a category of software which automates processes that can span multiple applications across an organization. These platforms emphasize the word “automation” because they are not focused on merely the challenges of integrating. In fact, the standardization of APIs has made the integration part of automation much more straightforward than in years past (Ortiz, n.d.). These platforms also tend to focus and speak in terms of business processes and incorporate “low code” capabilities that allow non-programmers to implement solutions. So the role of the Solution Architect is to architect business solutions that span multiple business domains, and while they help ensure the APIs support those solutions, their role has been elevated to what Bloomberg calls the ‘architects of change’ and the realization of business transformation and agility.
Sources:
Blechar, M., & Robertson, B. (2010, December 08). Application Architecture Overview, Part 1: General Context and Scope. Retrieved from https://www.gartner.com/doc/1487814/application-architecture-overview-general-context
Ortiz, A. (n.d.). Save Time Building Integrations. Retrieved from https://tray.io/lp/guide/beginners-guide-to-general-automation-platforms/download
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/
Robotic process automation. (2018, August 13). Retrieved from https://en.wikipedia.org/wiki/Robotic_process_automation
Your posts really really made me think about how things are being approached in my organization. Silos are something that my organization deals with – although recently things have been a lot better. I think part of the improvement is due to our new cloud “first” strategy and our renewed focus on having a formal EA team. While EA is part of the IT services team (app dev, ERP databases/integration/management, networking and systems administration) I think we will continue to gain traction and influence in the organization. One area where I identified with your post has to do with automation – my team is focused on automating as much as we can across our team. This has brought the networking/cloud teams closer together as they will have a common automation platform to deliver infrastructure services – so one silo is being removed between these two groups at least. The platform is low code (yaml playbooks) and provides API services along with our cloud vendor.
The adoption and migration to cloud and SaaS has definitely caused us to reevaluation how we “do” IT on a daily basis. The teams are more aware of technologies and solutions and how the EA/cloud engineering team can help streamline and automate their functions. At first we were met with resistance, but people are beginning to realize that automating even the daily mundane tasks helps to reduce errors and free teams up to do more high-profile and more interesting work.
Per your second post, we are also looking at having a Solutions Engineering team that will work with EA and the sub-teams. Hopefully we will realize the changes we are seeking to bring about. One question we do have is how can we go about breaking down other silos that aren’t part of our immediate team? Many business units have their own IT liaison resources and have in some cases gone in their own direction. Hopefully the strategy will work in a larger context