Tag: Application Architecture

Organizational silos are a 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 (Grainger, 2018); however, there is also benefit from busting the silos of people and technology that have formed around the technology stack. In this post, I will discuss how some emerging technologies are promising to bust the silos that exist between organizational units, both horizontally (between busines units) and vertically, between the technology stack.

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, 2018). Although it is increasingly common to see applications or application suites packaged with workflow capabilites, thes are typically intended to be utilized within the application or suite. Other achronims in this technology domain would include Business Process Managment (BPM) and Workflow Managment Systems (WMS).

These platforms offer a wide range of capabilities but some comon features would include: connecting API enabled services, visual workflow builders, logical operators (e.g. if this then that or ‘iftt’), event triggers, reporting dashboards, data transformation, data storage, processing scalability, alerting/notificaiton, collaboration/imbedded communication tools, and often security/compliance features to provide tracability to  monitored transaction types.

One of the most important features of these platforms is that they often do not require coding to configure or manage. This “low code” capability is targeted towards business users or ‘citizen coders’ to quickly depoy new solutions. This capability is a great example of busting the silos of people and technology that have developed around the technology stack. For example, to develop the most basic web application could require a UX designer, web developer, database administrator, application server administrator, and a network/infrastructure engineer – not to mention the project manager, testers, business analysts, and other supporting roles. However, as cloud technolgies take over each level of the stack, these either cease to exist or they are replaced by roles that combine the previous functions, like cloud architects.

As I had written last week, 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 (Hawes, 2012).  There are implications for the role of the enterprise architect as well.

 

Sources:

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

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/

Ortiz, A. (n.d.). Save Time Building Integrations. Retrieved from https://tray.io/lp/guide/beginners-guide-to-general-automation-platforms/download

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