Back in the 90s (yeah, I am unfortunately that old), I started my career as a Business Process Reengineering (BPR) consultant. I would drive around, interview clients about their business processes, and then model each process in a tool called ARIS (what old people used before Lucidchart). We then printed all those process visualizations, hung them up in a conference room, and spent nights and weekends coming up with process improvements.
Call me weird, but I was always fascinated by the complex universe of business processes. I thought I had the coolest job in the world.
It took about 20 months until frustration came onto my “perfect life”. The trouble started when I began to check on the IT implementation results of my process reengineering work. What I saw literally put tears in my eyes. Why did I work so hard when this was the outcome? In my 4 years as a BPR consultant, this disappointment repeated itself many times over. At some point, I decided to stop checking the results of my work.
Things got better when I left consulting to become a product manager (PM). Different from the world of business processes, it was understood that it takes multiple releases to build a great product. PMs and engineers collaborated together in Agile Development teams. But of course, building products requires a scale of resource investments with dedicated product managers and many software engineers that would never work for internal business processes.
Sometimes at night, I would dream of a world where a reasonably technical process analyst and a general IT resource could work closely together to build out great and ever-improving business processes. I asked myself why someone like a Salesforce admin/consultant couldn’t get the job done end to end. But I already knew the answer: The right tools simply didn’t exist.
Wait, I am not alone…
Fast forward almost 25 years, and clearly I am not the only one who had and still has to face these challenges. Building, maintaining, and evolving great business processes is still a challenge today, no matter if it’s a small and agile start-up or a really old legacy business. Building an Agile Enterprise is still the frontier.
Many small companies often ignore the problem altogether and simply stick with messy workarounds; while larger companies can’t seem to shed the straight jackets that old legacy systems feel like.
This goes beyond my personal frustration and disappointment as a process consultant. It’s a real problem that’s holding practically every business in the world hostage.
That’s why I got so excited I couldn’t sleep for days when co-founders Vijay Tella and Gautham Viswanathan showed me Workato in 2014. Workato felt like the platform that could finally end the ongoing frustration. This was the “Enterprise OS” that a truly agile business could be built on and that catered equally to the needs of a modern tech company, as well as a large legacy business.
Is agile just for Development Teams?
Having been both a process consultant and a product manager, I am always surprised that “Agile” seems to be understood only in the context of software development teams. Every software development organization today practices “Agile”. They use a platform like Jira and, in groups of less than 10 people, run 2 week sprints to iterate small chunks of code. But when I talk about “agile business process building”, I get weird stares. Somehow, “Agile” only seems to apply to developers and PMs, not to IT generalists and business analysts. Why? Requirements for business processes can change rapidly. It’s impossible to anticipate all exceptions in the initial process implementation. The agile model of multiple iterative implementation cycles are just as much beneficial for business processes as they are for products.
One of the leaders who gets it is Andy Nallappan, longtime CIO of Broadcom and now their CTO and Head of Software Business Operations. His take: “If you can’t show me results in 4-6 weeks, I’m simply not going to do the IT project.” An agile Enterprise OS that facilitates such fast iterations of process changes makes a lot of sense, just like DevOps tooling makes sense for developers.
How do you quantify the value of an Agile Enterprise OS?
When I describe Workato as the one platform that has all integration and automation capabilities to implement business processes, I most often get the question: “How is Workato different from other integration and automation platforms?”.
Yes, it’s true that there are many integration and automation tools. Frankly, one of the reasons for disappointing results has been that there are too many specialized tools, each so complex it requires its own specialist resources. How can a business analyst ever understand a business process implementation when 5 separate specialist tools—an iPaaS, ETL, BPM, RPA and a workflow tool—are used?
What differentiates Workato is not that it does yet another novel specialist task that was not covered before. The difference is that Workato combines all of these capabilities in one platform that both a general IT resource and a business analyst feel comfortable with. That’s a big accomplishment and that’s the “Agile Enterprise OS” needed to overcome a decade-old problem.
When this realization sinks in, I typically get the follow-up question: “and how can you quantify the value of the Enterprise OS?” First to mind, of course, is speed. Time is money and by using Workato, a process is implemented 5 times faster than with traditional specialist tools. TCO (Total cost of ownership) is next. Workato costs a fraction of the 4 separate specialist tools (iPaaS, ETL, BPM, RPA) combined and doesn’t require costly specialist resources.
These are the primary benefits, but the secondary benefits are also incredibly valuable. The 5 times speed advantage means that process quality goes up dramatically. And because not just specialists can participate, you can address many more processes than before. You don’t have to stop at the 2 big processes: “order to cash” and “procure to pay”….now you can tackle hundreds of smaller processes as well.
Can’t we work together?
David Peterson described the core impasse really well in his article: “The people who feel the pain of the existing process, and know what needs to be done to fix it, aren’t able to solve it. And the people who can solve it, don’t have the time or understanding to solve it well.”
The crux was that we create business processes in 2 separate worlds. In one world, business people with process understanding defined a process strategy. In another world, IT experts with little processes understanding then implemented these processes with an array of really complex technologies only they could understand.
If you Google search “Business IT alignment,” you’ll quickly understand the magnitude of this problem. The fundamental problem: the lack of a platform powerful enough to run a large business on and easy enough for a business analyst to not feel intimidated by.
What if the business analyst could easily collaborate back and forth with the IT counterpart on the process design? What if they used one platform they both felt comfortable with? What if these 2 separate worlds would come together?
Wait, won’t SaaS solve that problem?
Of course, there have been previous attempts to break down the business/IT barrier; most of them unilateral attempts. SaaS (Software as a Service) was one of those attempts. The idea is simple: build applications that run in the cloud without any IT help. This way, the business can just circumvent IT and buy all the business processes “out of the box.”
SaaS clearly is the future of IT, but it alone hasn’t fully solved the business process challenge. We’ve seen mid-size companies with over 200 SaaS apps. Every business department picks its very own best-of-breed SaaS. And every business beyond the smallest mom and pop shop differentiates with customized SaaS implementations. The result: even more disintermediated business processes. SaaS has solved the problem for the departmental processes of a given department. But at a company level across all the departments, the challenge has become bigger, not smaller.
Why not just hack it with RPA?
One other “miracle drug” seems to be RPA (robotic process automation). Many thought they could use it to workaround IT people and their APIs, and automate manual processes with robots that simulate employees using the applications’ user interfaces. That’s like Excel macro recordings, but across all your business applications. A few years into this experiment, what sounded like “duct tape” in the first place didn’t fully solve the problem either. Not surprisingly, RPA leads to a continuation of messy workaround processes with lots of spreadsheets, but now scaled with robots (leaving IT to fight all of these issues at an automated scale).
Needed: the Enterprise OS
The classic take is that a tool can either be easy to use or Enterprise-grade. That means that if it’s easy to use, by definition it has to be “a toy” that only works for a small scale Enterprise. If it’s Enterprise-grade, it has to be super complex and can only be used by a specialist resource. These are the “rules.”
Workato, as a 3-years-in-a-row Gartner iPaaS leader, is clearly Enterprise-grade. At the same time, as we discussed, business analysts are comfortable with Workato. This combination is not supposed to exist and hence raises suspicious eyebrows. How is this possible?
First of all, we’ve designed Workato for a non-specialist builder. The type of users we had in mind were technology-savvy business analysts on one hand, and business-savvy IT generalists on the other.
For simplicity, let’s think of a Salesforce Admin/Consultant. They are technical enough to configure Salesforce and have a solid understanding of sales and support processes. A Salesforce Admin/Consultant is used to Salesforce’s native workflow tool called Process Builder/Flow.
Workato also focuses on workflows and business processes. We deliberately did not model Workato off of a traditional integration tool that just moves data. Workato turns APIs into “business events” and lets business analyst users define “if this then that” style business process flows we call “recipes.” To build an integration or automation is all Configuration. No knowledge of the underlying API or JSON data representations required. Workato recipes aren’t “polluted” by technical details, and therefore business analysts can follow the business logic expressed in Workato recipes.
The Enterprise-grade nature of Workato is enabled by Workato’s modern architecture. Workato offers a fully-serverless implementation with extreme scalability through modern container technology. Case in point: Snowflake certified Workato at 500,000 records per second. And uptime is never in question as Workato is implemented as a fully reliable cloud service with strong monitoring and management capabilities. Top notch security, development lifecycle capabilities, transparent reach through firewalls and extensibility are never in question, driven by Workato’s engineering team with decades of Enterprise middleware system design experience.
The result is the agile Enterprise OS that both business analysts and general IT are comfortable with and that changes the business process conundrum that has plagued all kinds of Enterprises for a long time. This is what the future looks like.
