The impact that Services Oriented Architecture (SOA) has on an organization is deep and wide. The changes required to bring SOA to fruition and make it as productive as possible affect the way both IT leaders and business managers think and operate.
To provide a solid foundation on how SOA impacts a business, Dr. Paul Brown, a principal software architect at TIBCO Software, recently wrote "Succeeding with SOA: Realizing Business Value Through Total Architecture." The book emphasizes a "Total Architecture" perspective for SOA and advocates how business processes are the real focus for enterprises to prosper.
Many activities that used to be done manually either completely or partially now ingrained in IT systems. SOA helps elevate those activities into loosely coupled services with standard interfaces so they can be used and reused flexibly within business processes, while leveraging the underlying IT assets and automation benefits.
Dr. Brown calls on businesses to define, fully grasp, control, manage and adjust the processes as rudders that steer overall business agility, powered by SOA methods. However, enterprise business processes and enterprise IT systems are so intertwined that you can’t really talk about designing one without designing the other -- hence the need for "Total Architecture."
In this podcast, Dr. Brown is interviewed about his book and the concepts of Total Architecture by enterprise architect Todd Biske, with moderation by myself, Dana Gardner, principal analyst at Interarbor Solutions. I do hope that people take a look at this book. I think it has a lot to offer.
Here are some excerpts:
The structure and organization of IT is very often not completely aligned with the business. The care and feeding of the IT infrastructure has become a focal point of a lot of the IT investment. What we’ve lost is the connection between what’s going on in IT and what’s going on in the business.
The structure of our IT solutions are difficult to map onto the structure of the business processes. It’s that realignment that we’re trying to address with SOA. Ideally, the services that we’re building -- that have technical implementations -- are building blocks of business processes.
The real business value comes out of having a portfolio of business functionality in the form of services that you can quickly reorganize and re-orchestrate to build new business processes or to modify your existing processes. That’s where the big business win comes in.
Dr. Brown points out that a lot of times IT may be misaligned and not be able to see the business processes that are spanning the silos. It may also be the case that the business isn’t either. So, you’re really setting up challenges, when you’re trying to view things from more of an enterprise perspective.
... The pressures of globalization make viewing your entire enterprise and your business as a whole even more important. It’s hard to continue to operate in a niche and continue to sustain that organization for many years, whether it’s from the IT aspect or the business aspect.
It’s distressing, when I go into a company, how infrequently I find anybody who can articulate what the end-to-end business process is that produces the key results or can tell me what the entire order-to-cash cycle looks like. There are lots of experts for fragments of it. The IT focus has traditionally been on fragments of the processes.
The pressure these days is to improve the overall business process, the response time to the customers and partners, and the overall quality of what’s going through. So we need this focus on end-to-end business process and the focus on the end-to-end system interaction that helps bring that business process to life.
What we need to introduce into the picture is more thinking in terms of how these different silos play together to make the business work. That has to happen on both the business side, looking at business processes, and the technology side, looking at systems.
... We need a proactive enterprise architecture group that’s willing to roll up its sleeves and get its hands dirty, touching the individual projects that are going on. They really need to coordinate their work, so that we don’t end up with the chaos that we’re in today, and so that we have pieces that elegantly fit together and can be rearranged to achieve new business goals.
When you design a business process, you’re making assumptions about what systems are going to do and what people are going to do. You can’t validate the assumptions until you actually start doing the technical design. You need to have a systems architect involved when you are planning business processes.
Conversely, you can’t really make modifications in the system without inadvertently changing the business processes. So it doesn’t make sense to separate these activities. You really have to treat them as if you're architecting the business, which consists of both business processes and systems.
One of the things that was impactful for me was the notion that SOA can be a catalyst to thinking about things differently and bridging this business-IT chasm. And also that SOA can be a precursor to a whole new conversation about how to think about businesses from this perspective of "Total Architecture."
... Your business processes and your systems are intertwined, and the design of one affects the other. That’s reality. You can choose to ignore your business processes and let them evolve by accident, as Todd was talking about earlier. That’s how we got in the bind we’re in right now. To a large extent, we’ve been focused on individual profit centers and driving down cost in individual functions. We’ve lost sight of the end-to-end business processes.
The resurgence of interest in customer loyalty, customer service, and all of that is really a reflection that, as a business, we need to stand back and look at what we’re doing to our customers and our partners. The investments we’re making and the individual activities in the business processes are fine, but in order to remain competitive we need to stand back and take the holistic view. The holistic view simply means you need to understand what that business process looks like before you can improve it.
I’ve seen horror stories of people who have tried to improve a business process by examining a small portion and making some changes, without realizing that the changes that they’re making are having an adverse impact on the bigger business process. So while they thought they were improving things -- they actually made them worse. You can’t live with that.
Read a full transcript of the discussion. Sponsor: TIBCO Software.