SOA: Requirements and Architecture

In the past 5 years, SOA has made enormous leaps and bounds. Some organizations swear by it, others swear at it. But one thing is for certain... CIO's love it.
Why? Because SOA makes the business feel like they are in control.

What is less understood, is that SOA, like its predecessors (COA, OOA and POA), is still Architecture, which puts its application in the hands of technical, and not business people. What SOA does provide is a simplified way of business people and technical people to talk to each other. This talk happens in terms of:

• Business Process
• Services

Business Process
One of the architects that puts this brilliantly is Brian Petrini. In all his seminars that I attended he made it a point to say that an SOA should always first be described in terms of the "current process" and then later refined to a "better process".

My own definition of a business process is: "A business process is a set of steps/actions undertaken by one or more business units that has a specific business outcome."

As such it is my opinion that only a business person can define a business process.
Business tasks are also in the realm of a business person.
In essence: The business process and all the steps/actions that it entails are within the domain of "The Business".

This brings us to a clean outcome... namely that "The Business is responsible for defining the Business Process".

In many an occasion I have found that The Business misunderstands this to be "The business is responsible for Automation of the Business Process" just as many times as I have seen technologists believing that "Technology is responsible for defining the Business Process".
To be truthful, both automation and definition of Business Process may influence (but only influence) each other.

Business Service
I define a Business Service as: "A set of repeatable (and related) Business Tasks that are performed by a (single) Business Unit that attribute to a know Business Outcome for which that Business Unit is responsible".
As you see, the description of a Business Service is almost identical to the one of the Business Process with the following
exceptions:

1. A Business Process is not necessarily performed by a single Business Unit, but may consist of "collaboration between" different Business Units.
2. A Business Process has a specific Business Outcome, just like a Service, but that outcome is not restricted to be the responsibility of a single Business Unit.

In fact, these small differences make it possible for me to assert that a Business Process is a special Business Service that has the whole business as the responsible provider of the service (rather than just a single Business Unit). A Business Process generates overall outcome, whereas a Business Service generates specific outcome.

For example:
The business process defined for an insurance claim, aims to provide the single outcome of a processed claim (which is either paid out or declined).
The business process of a money transfer provides the single outcome of a completed transfer (either credited and then debited or rejected in its simplest form)

However, many business services may have been involved... For example
The claims process involved a Fraud Check (provided by legal services), a damage report (provided by valuation) etc...
A money transfer process involved a Disposition Check (by Accounts) and a Transfer Route Calculation (by Interbank Transfer) etc...

As you see, even though each service has a specific outcome, there is no holistic process outcome (no end-to-end result). The process however did have an end result.

So what does Architecture have to do with all this?
This brings me back to the "who is responsible for what" question that Business and IT sometimes get entangled in.
Most of the time the Business wants to ship a product fast or change their strategy in an ad-hoc fashion. Being the owners of the Business Process and the Business Services, they want to dictate "HOW" these changes should be made and this is the problem. Changing a Business Process is not the same as changing an automated Business Process. Implementing a Business Process is not the same as implementing an Automated Business Process.

So how is this different?
This is different because of Service Level Agreements and Key Performance Objectives

Both of these points have a Business, as well as a technical impact.
The choice on how to implement a Business Service may have far reaching repercussions on the key architectural markers (Architectural KPI) e.g.:

• Availability | The way in which a process is automated may affect availability e.g. during system upgrades or maintenance or when the system is under load.
• Performance | The way in which the process is automated may affect performance e.g. when the system is under load or the hardware environment is not up to spec.
• Reliability | The way in which the process is automated may work well if all the components/services are in operation, but what happens if one part fails?
• Scalability | The way in which the process is automated may not allow the system to scale if its use increases.
• Cohesion | The way in which the process is automated may be such that services are tightly coupled, which makes everything fail if only one thing fails.
• Complexity | The process or its services may be defined in too complex a way for these to be adjusted or maintained.

There are many more of these markers that influence the overall outcome, but they all lead to any the following being affected:

• Resources | People or Money
• Time | Time to Market/Time to Adjust

They i.e. affect the main reason for SOA: Management of TCO/TCA.

Architecture (and to a degree Development and Infrastructure), i.e. Technology Specialists are the ones who (should) understand technology and implications of technology choices. This takes many years of training and experience. Computer Architecture, Database capabilities (indexing and partitioning), network bandwith, compression, search algorithms, caching, queuing mechanisms, webservice complexities etc... etc... are things that Business People do not understand well enough to be able to understand the implications it may have to Architecture markers. It is therefore of vital importance that The Business describes their requirement (the what) and not the solution (the how), because no matter how simple it may seem... the underlying technology is still technology. We still deal with processors, memory, disk and network... In fact over the years these have become more and more complex (diverse) due to the
introduction of mobile computing, wireless networking, solid state storage devices etc... etc...)

SOA, Requirements and Architecture
So, what does this mean for requirements and architecture?
The business should describe:

• The information.
• Each step of processing the information (i.e. the order).
• What happens as part of processing the information (what changes).
• Who/what may access the information (and in which way... read, update, remove)?
• How long do we expect each step to take?
• How long do we expect the process to take?
• When should the system be accessible?

Technology should describe:

• How the information is stored (information storage... do we use a database?).
• How the information is transmitted (information format/exchange... will we use XML?).
• How each step will be interconnected (process definition implementation... are we going to use BPEL).
• How the information is changed (information processing implementation... will we use a business rules engine? do we use web forms?).
• How the system will make sure that the information is accessible according to definition (security... do we use single sign-on?).
• How the system will perform (performance... will we use caching? will we use compression?).
• How we meet system accessibility (scalability, reliability, availability... do we use HA? do we need failover? disaster recovery?).
• How do we make sure that IT professionals can be efficient in changing the system (homogeneity, cohesion, complexity... will we use pointers? how will we name variables? do we deploy on Linux)?.

The next 10 years will define how we adequately define the responsibilities of "The Business" and "Technology". SOA has taken us a step ahead. SOA Governance is only the cap of the iceberg. We need to further define what "ownership of technology means"... After all, how many business people fix their own car after a crash or decide to architect their own highrise? And how many technologists are brave enough to borrow millionsin one place and invest them in another? Like shortcuts in business principle and risk assessment, shortcuts and unsound technology decisions can cost a lot of money (infact it is costing us billions every year). Let those who know what they are talking about do what they have to do.