Nov 17, 2006

Service-Oriented Organization/Staffing

Increased focus on maintenance, modularity and components decoupling encouraged birth of new design patterns and design paradigms. After Object-Oriented Methodology being adopted as defacto in most of the part of software industry, focus on component decoupling increased, eventually giving birth to the revolutionary concept of "Service-Oriented Architecture".

Service-Oriented Architecture provided new dimensions to component-decoupling, distributed-computation and distributed-development. Architecture provided a simpler way to neatly draw those blocks in a software design diagram and cleanly connect them with a single-line. Two or more components interact with crystal-clear interface making them perfectly decoupled and implementation-independent.

So far so good. Now let's get a little more pragmatic and look deep into application in current software development scenario. Say, in a large software system, Service-Oriented Architecture is implemented and two subsystems, say Service1 and Service2, are decoupled as components providing services to each other. Services are exposed for each subsystem by a common development team.

The development team managing both the subsystems has detailed knowledge of internal implementation of these subsystems; and this is one factor that could prove to be the biggest disadvantage to the original architecture.
Suppose, Service1's function someoperation() is exposed as a service and it needs to update a database value, which actually belongs to Subsystem2. This should ideally be done by -
  • Service2 exposes function to update the database field
  • Service1 invokes this function of Service2 to update the field value
Unfortunately, this is not a perfect world. Development team might intend to deviate because of the triviality of the operation and rather more effort involved in exposing (and invoking) a function as simple as a getter or setter. Consequently, this may lead to chaos in an architecture that was intended to be Service-Oriented.
Ideally, these scenarios should never have happened. Practically, they do; more often than not.
To overcome these one would suggest to focus more on the guidelines, strict reviews or what not. But very source of the problem cannot be ignored - access, knowledge and co-existence of subsystems. I would suggest a solution that follows: Service-Oriented Staffing.

Service-Oriented Staffing
Either it's Service-Oriented architecture or not, software development teams could be organized in a service-oriented fashion by providing services (corresponding to business function of the software) to one another. The system areas can be restricted to each team and teams communicate on a strict protocol basis. This would give distinctive advantage in terms of adhering to strict architecture or design because:
  • Teams cannot access other subsystems' data without invoking a service
  • Teams cannot "directly" perform a business function that was intended to be performed by another service
  • Because they are different teams (at least logically), they can sit together and finalize on the type of operations that must be exposed

Because every single access of another subsystem required goes through a strict process of deciding on service functions to be exposed, it could become highly impossible to deviate from the intended architecture.

Teams could prove to be more independent in their functional area and probably achieving an expertise much faster than in a common-team project.

Application to any architecture

Although, it sounds that Service-Oriented Staffing can be applied only to the software systems that follow Service-Oriented Architecture(SOA, it's not the case though. One could organize development teams in a service-oriented fashion by aligning their business functions and then dividing the system's area among components/teams. However, it would almost be impossible if the business functions in a software system cannot be logically grouped together. Steps below describe how a non SOA system could follow Service-Oriented Staffing and get the benefits of decoupling:

  • Group together the business functions of the software system. More than one group must be identified.
  • Carefully divide the data (database and files) among these groups
  • Staff/Organize the team into these groups
  • Improve these groups by inducting more functions to remove inter-dependencies
  • Restrict the inter-group direct accesses

The whole process could either be made slow by first getting prepared for Service-Oriented Staffing, or Staffing could be rolled out in one-go and then stabilizing the system slowly. Both approaches would have balanced trade-offs though.

SOA is just not a software design tool, but has much more in store for the interested ones!

TheServerSide.com: News