The more mature process automation programs get, the more important the role of Enterprise Architecture becomes. We have been a part of automation journeys that leverage Robotic Process Automation (RPA) solutions and other enablers of Intelligent Process Automation- from business case development to rapid prototyping, all the way to a sustainable Center of Excellence across business units. ONE TREND HAS REMAINED CONSISTENT- repeating transformational successes across business processes is nearly impossible without involvement from an Enterprise Architecture (EA) team as an internal partner.
In fact, CIO.com ran an article on this topic last year titled ‘Why you need an enterprise architect’. They found that business process change is at the core of the services seeked by the business from the EA team:
“There was a 75% percent increase in the number of job postings for ‘enterprise architect,’ particularly among large enterprise organizations who are adopting service-oriented architecture (SOA) and those who are investigating technology and business process change within the organization.”
But what if you don’t have a central EA organization? What if you have a federated model with Solution Architects sitting in the lines-of-business over Enterprise Architects? Outside of telling you that you really should re-evaluate the need to have a formalized central EA team that acts as an internal technology consultancy, our advice is to structure a swat team of architects that can help as it relates specifically to RPA initiatives.
This isn’t your grandfather’s EA function: Defining ‘Modern EA’
There are many different definitions around what an EA should be, and what type of responsibilities they should have. When we talk about Enterprise Architecture at Ashling Partners, we distinguish between the EA 1.0 of yesteryear, and what we call ‘modern EA’. The EA of yesteryear was well-intentioned, but ultimately led to fragmentation of solutions and teams (ie ‘Plan, Build, Run’) as opposed to a truly enterprise view, and Service-oriented Architecture (SOA) led to a disparity of the services that IT had to offer the business, and the services the business really wanted. Modern EA functions tend to take a more holistic enterprise view from both a system and a business perspective. Modern EA functions tend to be DevOps organizations (basically Agile with tools to support the process). The function requires a startup mentality with a process framework and scalable rigor. We find that many effective EA organizations have some of, or all the following characteristics and roles:
‘Modern EA’ increases your chance of success for RPA programs
The characteristics and roles of a modern EA function defined in the above section apply strongly to the components needed to scale your process automation program. Here are some thoughts on how the ‘modern EA’ can really speed up that automation flywheel in a scalable way:
• Business-Outcome orientation: Modern EAs keep the tool in mind but lead with business acumen. They build a trust with their business stakeholders. With a modern EA skill being a business-outcome driven approach, the EA team can help navigate cross-functional teams thru tool inundation and bring clarity to our efforts: Growth, productivity, cost improvements, quicker times to market, less manual intervention, etc. It is the evolution from delivering ‘projects’ towards delivering ‘outcomes’. One of the most exciting aspects of RPA is the tangible business outcomes it can deliver, which aligns well with this modern EA trait.
• Agile Vendor Evaluation: One tool is unlikely to solve every unautomated activity in your organization. Ashling Partners estimates that large enterprises will have, on average, 3-4 RPA tools in their environments by 2021. Add to that the fact that the leading RPA platforms have very quickly advanced their platforms to incorporate cognitive capabilities around unstructured data, your organization now must navigate across increasingly blurred lines to compare technologies that today seem like Apples (i.e. UiPath, Automation Anywhere, Blue Prism, Workfusion) to Oranges (IBM Watson, Google Deepmind). And this proliferation of automation and artificial intelligence options will only continue to grow. Therefore, modern EAs must manage even more sophisticated solutions as well as navigating all the different vendor-specific architectures- this has contributed, at least partially, to the rise of DevOps.
• IT Strategy enablers: According to APQC, a ‘top 3’ reason why Automation Programs fail is due to a lack of clear, documented strategy for process improvement and RPA. A modern Enterprise Architect is someone who can translate a company’s business strategy into concrete solutions, from strategy and architectural design & blueprinting, through execution and support to drive the ongoing strategy. An EA function seems to be just the right team to ensure strategy stays aligned with reality, and that concepts cascade down into action.
• Standards and governance: Standard architectural frameworks and methodologies like TOGAF are not new concepts. The modern EA function is intended to serve as a business enabler while enforcing standards and governance across security, platforms, integration, and vendors. This can sometimes feel binary and is not an easy balance to find. With the increasing amount of ‘best-of-breed’ solutions on the market, the modern EA function acts more as a broker as opposed to ‘team NO’. With advancements in integration options (see the next point), this becomes easier, but there are still challenges around data normalization, security, vendor management & negotiations, and learning curves for new tools. With this expertise of the modern EA function in mind, a large reason that Intelligent Process Automation programs have trouble scaling and becoming truly sustainable via a center of excellence is due to conflicting standards & governance needs. It seems to us that the EA team is well-equipped to guide an organization thru these phases.
• Integration Strategy: Integration Platform-as-a-service. The API Economy. Custom ETLs. Enterprise Application Workflows. Nobody can argue that we have a lot of tools in our integration toolkit nowadays. The promise has been easier, quicker, and less expensive options to integrate disparate systems to keep pace with the business, including data sets that are not within our company’s firewalls. The modern EA team really should own the integration strategy as they have the most holistic view of the enterprise ecosystem. With RPA being a ‘quick and dirty’ way to mimic integrating systems where the business case may not have been strong enough previously for a more robust solution, the EA team needs to understand RPA solutions and leverage them as a less expensive and time-consuming option than robust integration solutions. Since they should also own the Enterprise-wide integration strategy, they are integral in leveraging RPA across multiple systems.
• Modular Reusability: Depending on the RPA vendor you work with, you may have the ability to ‘recycle’ robots. To effectively do this, you need an architect that can conduct a quick fit-gap analysis based on business outcome variance and the corresponding re-design of the bot itself. And you guessed it… The modern enterprise architect is a great person for that job.
The SWAT Team: Ideal RPA candidates and the EA team
With the above points in mind, it is also important to know that RPA isn’t the answer to every question. As a refresher from earlier blogs on RPA candidates and outcomes, when we look at the ideal candidates for RPA, we look at the following buckets:
Again, an EA organization is well-positioned to, at the very least, help guide the organization through use case identification and prioritization across all five of these buckets.
As you can see, we think that the EA function is extremely critical to testing and scaling RPA, intelligent process automation, and whatever form of artificial intelligence that hasn’t even been invented, yet. Is this the only way to achieve automation success? Of course not. But we have seen too many RPA programs not live up to their original business case. The ROI is never fully realized when a program can’t scale with speed and a sound foundation. There is a reason why you call in the SWAT team when you need to move strategically and swiftly. Our recommendation is to view both your EA function and your RPA program in the same manner.
