Process Orchestration is a Tool in Your Enterprise Architecture Toolbelt

I’ve always thought Batman would be an amazing enterprise architect. The way he studies and visualizes the city of Gotham, creates solutions to take out the bad guys, and the many tools he has in his utility belt… He’s constantly thinking about the bigger picture and how everything moves while staying focused on the mission at hand. A bit like an architect mindset. Okay, maybe that’s a stretch for you, or you’re not a super big comic book nerd like me.

Enterprise architects don’t just look at IT architectures; they must understand the company’s mission in sufficient detail to make informed purchases and architecture decisions across the enterprise. Enterprise architects commonly make high-level design choices on all things IT and propose technical standards, including coding standards, tools, or platforms.

The reality of an enterprise architect is that every day, you drive change by tying the business and IT landscapes together. You consistently translate the needs of the business to IT teams. While they may have difficulty getting on the same page, you sit right in the middle of it all, navigating your organization toward success.We’ll talk about the connection between Enterprise Architecture and Process Orchestration in a bit. But first…

What are the tools in the toolbelt, anyway?

We’re not talking about concrete tools, but rather:

• Visual diagrams: Visualizing what your systems look like via a series of images that tie your infrastructure and applications together via real-world scenarios (if these exist, that is).
• Collaboration: Creating collaboration between the business and IT teams, ensuring that everyone is on the same page.
• Expertise: Most architects have an incredible amount of time working in the field (10-plus years sometimes), building trust and know-how wherever they go. This is typically someone that works at building reliable systems either in the cloud, on-premise, or some level of hybrid architecture.
• Data distribution/data flow: How does data flow from one application to another? What dependencies are there?
• Performance benchmarking: What is the behavior of our systems when things are running well? When do things begin to fall over as we hit a certain amount of traffic?

• Knowledge of how to implement best practices: Architects need to understand practices like best in class security, API gateways, event-driven architecture, and scalability.

Meanwhile at the Legion of Doom… Challenges in EA

I first became a cloud engineer almost a decade ago, and I was so excited to learn! One of my onboarding exercises was to meet with the architect on our team. He walked up to a whiteboard and walked me through what all of our services looked like at the classic 10,000-foot overview. I bombarded him with question after question: “How does this work? Where is this documented? When’s the last time we tested this failover scenario?” He’d shrug with a grin and show me some outdated documentation, which is when I realized a lot of this lived in his head.

For architects, it’s not about how many tools are in your toolbelt, but how and when they’re used. The business folks don’t necessarily care about the nitty-gritty work the IT team is doing to create horizontal scaling across a variety of servers. What they do care about is the impact that those decisions have on the rest of the business—and customers.

Your customers’ expectations have never been higher: immediate gratification and little to no patience. Bizzdesign has an excellent State of the Enterprise Architecture Report they released this year that states that enterprise architects need to marry those expectations with the rising need to cut costs while also driving the conversation between business value and IT implementation, and things can get really messy. Business requirements change rapidly, and IT teams start saying no, choosing to go their own way.

To the business side, it feels like IT is ignoring the needs of the business; to the IT side, it feels like the business side doesn’t respect their workload. Who lives in the middle of that friction? You. Like Spider-Man holding a bus on one side and a train on another, you have to balance both of their needs, while also driving home business value.

Meanwhile, how’s that documentation look? Are those visualizations up to date? What’s missing? Those failover scenarios again?

Then there’s the big word that a lot of people are scared of: change. The reality is change is inevitable. It is incredibly challenging to take advantage of the technical innovations of our time without it. Not to mention it’s difficult to deliver the digital transformation that almost every company is attempting in order to keep up with their competitors without full visibility into your environment.

Where enterprise architects come in really effectively is balancing the needs of the business and the IT implementation and helping break down those barriers, being the interpreter between both groups.

Look in the sky! It’s a bird? It’s a plane? It’s process orchestration!

So what’s missing? There’s a big gap in sustainability when a process relies solely on the knowledge of said architect to tie SO many things together technically, while also attempting to manage the relationship between business and IT, all while driving home value across the board.

Fortunately this is where process orchestration can help. Process orchestration coordinates the various moving parts (or endpoints) of a business process, and sometimes even ties multiple processes together. Process orchestration helps you work with the people, systems, and devices you already have, while achieving even the most ambitious goals around end-to-end process automation.

The power of process orchestration is that it allows enterprise architects to connect both business and IT stakeholders, showing not just the stakeholders but the entire organization that we can:

• Visualize what’s actually happening: As much as we love those whiteboarding meetings that try to explain all the moving pieces, it’s likely that what’s drawn and what’s actually implemented aren’t the same. With process orchestration, that is no longer the case. What’s designed is exactly what’s implemented and executed. Now of course, that’s really easy to say. But in order to accomplish this, you have to have a platform that is responsible for defining, managing, and executing the sequence of tasks or steps that constitute the automated process. It ensures that tasks are executed in the correct order and handles dependencies between different steps.
• Get business/IT speaking the same language: Align business and IT using a common, standards-based model and language. With process orchestration, you can build one model across the entire customer journey using BPMN (business process model and notation, the ISO Standard for modeling and execution), visualize how all your processes perform, detect bottlenecks with ease, get notifications about errors, use machine learning to recognize patterns, or dive into heat maps to see what’s really happening.
• Tame complexity: You don’t need to eliminate complexity; instead, you can tame complexity through end-to-end orchestration across your customer journey.
• Drive home business outcomes: Organizations are more likely to invest in enterprise architecture teams if they can drive home value to the business. When you’re utilizing true process orchestration, it’s much easier to tie the business and IT value conversation together.

So how do you get started with process orchestration?

A phenomenal question! Here’s how you can get started strategically:

• Create architecture overviews: When you draw diagrams on a whiteboard, in many cases what is implemented is not the same as what is drawn up, but when you design an end to end process you can implement it right away using a process orchestration platform.
• Identify pain points: Start by identifying the current pain points in the organization’s processes. This could include inefficiencies, high error rates, long cycle times, or lack of visibility into processes.
• Locate end-to-end process: Locate the new to-be-orchestrated process on the process landscape. This allows you to easily find the start and end points of the end-to-end process and helps to follow and benefit from industry standards.
• Define customer touchpoints: Detail the end-to-end process with important customer-facing events (e.g., all needed customer documents obtained, quote created, etc.).
• Define process goals and KPIs: Create a process profile describing the process and defining the process goals and KPIs. Derive process goals from the given business strategy (reduce cost, increase quality, accelerate) and define process KPIs to measure these goals. Define internal targets or use industry standards as thresholds for the process KPIs.
• Validate business case with process tracking (optional): Calculate process KPIs based on existing systems events as an intermediate step before orchestrating the process.
• Orchestrate process: Ta-da!

All right, where do I begin with process orchestration?

Organizations are more likely to invest in enterprise architecture when it delivers business outcomes, and process orchestration helps you do that. If you’re new to process orchestration, no problem! Head to Camunda Academy for free courses about BPMN, DMN, process orchestration, and using Camunda.

If you’re ready to experiment with your own processes and applications, sign up for a free trial. It’s a great way to start creating a top-level strategic diagram, followed by modeling a business process, and then a deeper dive as long as you have a business outcome in mind. We also have a community forum where you can join the conversation with other enterprise architects as they explore Camunda and its ecosystem. No need to be Bruce Wayne to get started.