BEYOND SOA IS SPOA

IT market in general - and software vendors in particular – have emphasized SOA paradigm (Service Oriented Architecture) being the silver bullet for actual and future software developments. Recent studies (e.g.: “SOA and BPM for Enterprise Applications: A Dose of Reality”, AMR Research Inc, May 2007), show how SOA is perceived/applied within enterprises, and what directions enterprises themselves should take in order to gain advantages from its adoption. Whether an enterprise is going to plan for SOA design or not, there are three major difficulties they have to deal with:

• Roles involved. Even when designing simple business services, many company roles are involved, therefore many skills play on the same ground using possibly different tools
• Implementation model. Being it either Waterfall, Synchronized or Single, a certain number of tools is required to support it. Even if marked with the same brand, platforms for implementing SOA are often a collection of different tools, sometimes not well integrated
• Organizational issues. They are much more complex than technical ones, and they often require a cultural change in order to be addressed

Sense software platform leverages on its SPOA (Single Point Of Accountability) key concept to go one step beyond SOA and address the above points. This paper illustrates how Sense implements SOA paradigm and how SPOA model offers a way to facilitate the cultural change needed to better exploit technology benefits.

A real-life scenario
The complexity underneath the development of a business service does not depend on the service itself. It depends rather on the complexity (organizational, cultural) of the company. Incredibly simple requests may require long time and a great amount of money to be accomplished.

Roles involved
Within a big company, many distinct roles have to participate to the entire process, from inception (business modelling) to the execution (operation). All roles belong to three major areas:

• Business. Basically the business owner and the business analyst refer to this area. They are responsible for high level description of business goals and for detailed description of business flow, data flow and user interaction
• Architecture. The technical architect translates business concepts into executable units with algorithms to be developed and/or systems to be used
• Operation. One or more professionals are required to develop, test and deploy the service designed by the architects. An additional role is required to monitor service execution and ensure its performances

From 3 to 7 (or even more) different roles are required to implement a business service. The number cannot be smaller and in a normal situation this results in delays, misunderstandings, different (sometimes incompatible) point of views. SPOA model (as described later) does not allow to decrease the number of roles, rather it offers an approach to service development that avoids most of the problems mentioned above.

Implementation model

There are three major models that companies use to control service lifecycle. Namely, they are the Waterfall Model, the Synchronized Model and the Single Model, as depicted in the picture below.

The Waterfall Model is a one way process (from business to operation) where every role uses its own tool/repository. The constructs of each phase are passed to the following one. Any change in any phase has to be manually managed.









In the Synchronized Model all roles belonging to Business and Architecture share a common part of the model, thus allowing a lot of information to be consistently maintained through the lifecycle. Actual benefits of this approach do depend on tool features.











The Single Model is the best one in terms of simplicity. One single model is shared among roles, and each one of them may use specialized tools, without affecting the model itself.





Organizational issues
The bigger the company, the bigger the number of roles/groups involved in the development lifecycle. It is not infrequent to bump into difficulties like misunderstandings and delays. In other words, different perspective or different processes that take part in the overall design may contrast one another.

BEYOND SOA IS SPOA!

The actual implementation of SOA within enterprises has to face the above problems, making it difficult to achieve the benefits of SOA. Sense – SENsitive Services Environment fully implements SOA and goes beyond it, with the concept of SPOA – Single Point Of Accountability.

The major concern of SOA is the architecture.
It has to deal with services in a technical perspective. Services, in IT world, are merely responses to invocations. No more than results of algorithms. Or, from a higher point of view, they are objects running on an underlying middleware. This has little to do with clients and customers, who think of services as real answers to real requests.

The major concern of SPOA is the business service. Whatever middleware is responsible for making objects running, in customer perspective the service is (for example) his/her balance displayed on his/her mobile phone, at any hour, with a good response time.
It is the business service (that is, the customer) to set the rules that will drive development, and those rules will live inside the service as long as it is running.

With Sense the service is a single point of accountability, from business design to operation execution. The more the design proceeds, the bigger the number of perspectives that converge on the service. Every perspective “added” on top of the service will result in a new Service Level Agreement (SLA) that represents and guarantees the goals of that particular perspective.

Sense implements the Single Model of development, letting every role involved in the entire process add its own information and set its own constraints. Even if a certain role uses its own tool (not integrated with the others), this will result in adding a SLA (Service Level Agreement) on the service, and that SLA will affect service execution over its life.

Sense and SPOA help companies solve their organizational issues. Software platforms, including Sense, will never be the answer to the organizational issues described, that mainly depend on the behaviour of individuals.

Nevertheless, Sense and its SPOA key concept bring a really new approach to development.
It focuses on cooperation: multiple roles converge on the same object, everyone of them being responsible (accountable) for its own perspective (SLA), while the object remains the same. It is a cultural change, that leads to improvement and higher awareness.

CONCLUSION

Looking at future plans for software developments, companies think of SOA as the paradigm to protect IT investments and exploit all the potential of information systems. When approaching SOA at enterprise level, three categories a problems arise: the number of roles involved, the development model and the organizational issues. All these seem to weaken SOA potential.

Sense - SENsitive Services Environment platform and its SPOA key concept, offer a way to build SOA applications and realize the promises of the paradigm. Instead of adding a new set of tools, SPOA redefines the concept of service, allowing it to escape from the cages of technical issues and go closer to who is the source of company profits, that is the customer. Once redefined, the business service collects perspectives over its design process, each one reflecting the point of view of the role that set it.

The task of redefining the service is both technical and cultural. In this way Sense introduces a different approach, that brings a decrease in development time, a more effective process and a better understanding of company goals. In Sense environment, it is called Enterprise Common Sense.