Role Models and Services

SOA - an architectural style centred around the concept of a service. It’s a popular approach though not without a few difficult questions if you want to get it right, chief amongst these being: what exactly is a service anyway? Next time someone is trying to tell you that SOA is the answer to all your technology problems try asking them a few simple questions.

What is a service?
What’s the difference between an interface and a service?
How many services will I have when I am done?

SOA may well be at least part of the answer for your organisation, but success does rather presuppose we can distinguish a service from a hole in the ground. If we can’t then it’s entirely likely we’ll make a bad situation much much worse.

For example, let’s say you opt for the de facto choice of utilising web services for your SOA. You could end up replacing all your point-to-point RMI, FTP, DCOM and ODBC calls with lots of point-to-point, slower, more brittle, more bloated, less scalable web service calls which require more skills and expensive tooling to support.

Oh dear.

Sounds like we’d better think of a good way to identify real services before we go anywhere near any technology.

Steve Jones is a fairly prolific blogger on the subject of SOA and predictably he’s put forward a way to answer the question in “how do you know it’s soa?”. It’s a nice succinct post that ends with the phrase:

if you can show how the organisation is set up around those business services then you can really say that you are service oriented in your bones.

This clearly detaches the SOA style from its technological implementation and points us toward the business structure.

On his example diagram you can fluently read each line as thing-at-the-start provides a thing-on-the-line service to thing-at-the-end, e.g.

Demand Management provides a Stock Level service to Supply

These sound very businessey, not technical, and the line-ends are organisational entities, not application nodes.

Why is this good? Because genuine business services that reflect the organisation are almost completely static. When our beloved employer, Gristle and Flint, sells widgets, there’s an Order Capture Service hidden in the organisational structure whose origins go right back to Adam Smith in the eighteenth century and even, in principle, two thousand years more to Plato - it’s called the Division of Labour.

Division of Labour

Given the pace of technological progress it’s easy to forget that what we call systemic requirements like scalability, resilience and consistency are all issues that had to be solved during the industrial revolution.

When textile production moved from its cottage industry roots to water and steam-powered factories, people had to diversify and specialise their roles. The guy that sat alone weaving hairy shirts in his cottage start-up couldn’t continue to perform the same role when employed at a factory.

The needs of scale dictated that when a new hairy shirt order came in, someone had to check it (to confirm itchiness, due date, weevils-per-square-foot were achievable) and pass it to production. The order-checker individual, in factories over a certain size, had to be distinct from the power loom manager, the foreman, the accountant, or the water boy.

Specialisation is an elegant way to meet systemic requirements. Our Order Clerk allows the factory to scale by capturing orders whilst others concentrate on production and stock control. He meets resilience and consistency by focusing on doing one task well. His job is “reusable” because it’s flexible enough to adapt to orders of different types (as long as it’s defined well, which we’ll come on to in a minute).

Division of labour created a kind of primordial SOA because specialisation requires clear contract-based services to enable specialists to communicate.

And, just as there is for SOA, there are other solution styles to consider before we get too excited and run off to start defining services. The Division of Labour has not been without its detractors: Karl Marx, author of Das Kapital, wrote in the Wages of Labour in 1844 that specialisation to pursue financial gains would result in workers being “depressed spiritually and physically to the condition of a machine” because the ultimate result of scale would be employees performing mind-numbingly ultra-specialist fine-grained tasks.

But then Marx did not have the benefit of experiencing computer software, which is really good at those kind of things, so alas his later work Ich bin im Facebook was never published.

Static-Dynamic Services

So let’s just check those claims out - can an Order Clerk role be both static enough not to require change and dynamic enough to enable it to process orders of new (largely unforeseen) types?

• Static Through Scale

  Our Order Clerk captures and validates orders. As order numbers grow he gets busier. In the lead up to the local village fete, queues to purchase hairy-shirts might start to form. The factory owner, Reuben Gristle (for this is two hundred years before the merger), does not want business to go to his arch rival Bartholomew Flint, so he hires another Order Clerk and scale is achieved.

The role hasn’t changed, but there are now two people performing it.

• Dynamic Through Diversity

  As with all commodities, prices tumble over time and Reuben’s profit margins drop so he looks to diversify into other house-wares. To achieve product diversity at reasonable cost he must look to reuse as much of his current business and organisational model as possible. Selling bedding, curtains, cloth, etc is a relatively minor business change from selling shirts, so the two Order Clerk roles are merely modified. They still collect orders, check them for completeness etc, but the order forms used for the new goods are variations on the originals. Delivery date is still there, unit type, unit cost, sales tax, total cost - just the unit attributes (curtain length, colour options) are different.

• Scale + Diversity

  With Reuben’s success may come problems. He can handle scale by deploying more Order Clerks and each clerk can handle new products by varying the forms that they use, but implied in capturing and validating the order is a contractual confirmation step that the goods will be delivered on the date requested. If many orders come in through different Order Clerks for multiple products (possibly based on the same raw materials) this contract may be broken, though this will not be immediately apparent to an individual Order Clerk or Customer.

  Reuben’s options:

  • He could focus on consistency by creating a new Order Manager role, whose task it is to provide an Order Confirmation service to the Order Clerks. Orders can still be taken in volume but they are only confirmed when the Order Manager says so. Depending on the relationship of Orders to Stock and Production Planning this may create a bottleneck giving poor old Reuben a limit to growth that was later formalised in Amdahl’s Law.

  • Or, Reuben could do some basic business modelling and risk assessment. Depending on order predictions, stock availability, turnaround time and margin of error for each, it may simply not make sense to limit scale and add a delay to the Order Clerk’s activity.

  What Reuben wants to avoid is unhappy customers and lost business. The first option (split the service) could cause this by extending the queue for hairy shirts until the people at the back get fed up and pop on over to Bartholomew Flint’s Emporium of Prickly Textiles. The second option (manage the risk) would be to accept the lack of consistency for the short time it takes to process the order, meaning the vast majority of orders would go through without a hitch and a small few would require a change to the delivery date. As long as a customer-friendly mechanism can be contrived to reconcile the original and new dates, business growth is theoretically limitless.

Back to the Future

Reuben wouldn’t be familiar with the words, in fact he’d probably call it ungodly malign witchcraftery, but option one would be taking him down an ACID architecture route for his front office, whereas option two is more centred in the BASE way of thinking.

Regardless of which way he goes, his problems are manageable because the Order Clerk service is modelled on an enterprise noun (Order) and the business actions performed on it (Capture, Validate), more actions means either extending the service to work on variations in the data or linking services together to provide new ones (Confirm). Where new subcategories of enterprise nouns are discovered there is always the risk of service proliferation, which can be mitigated by modelling the service payload as a Business Document (Order Form). The REST style takes this to a logical conclusion by modelling resources and transferring changes in their state via the service. Execute an “HTTP POST” to http://www.gristleandflint.com/order containing an XML Order Form and it will create a new Order resource. Call http://www.gristleandflint.com/order/1234 with “HTTP GET” and back will come the Order details in XML.

And SOA done properly can be pretty agile. One of the tenets of Agile is “You Ain’t Gonna Need It” or YAGNI - that is to say over-engineering your solution to deal with a whole host of perceived future problems is mostly a waste of time, because when you get there the problems you are trying to solve will have changed substantially. If you “design” a full SOA for your business and then start rolling it out you will more than likely fail, because you’ll be modelling thinking you are going to need it, when in fact you should add services when you already need them.

You can easily spot this if you find you have to change services frequently. Services that are both needed now, and structured around a business role (which is in turn aligned to the organisation as pointed out in the post by Steve Jones), are empowering and relatively static.

Roles and Services

The key to much of this is the word “provides” - if you can identify the provider role, then it’s easier to identify the services. Provider roles can be found in the organisation, not necessarily in the application landscape. This shouldn’t be too hard to adopt into daily practice either, as we’re fairly familiar with role-based modelling in software design and we all understand role-based access in our applications, which are mostly aligned to organisational teams of people.

So the first step is to find the roles that can provide the services, but how might this be done?

Roles and Business

In the historically offensive example above there was, by necessity, no mention of technology to solve business problems; they were all solved with roles, people and services. About the most common anti-pattern in SOA is to take an existing application and try to work out how to expose its functionality as services (usually web services). This isn’t wrong but it is Just a Bunch of Web Services (JBOWS), not SOA. However good legacy applications are, they tend to become a mishmash of business functionality over time, thereby representing many business roles and often only partial implementations of them at that. If you want to find real roles that can provide stable services, the last place you should look is at the applications you already have.

The first place to look is at the organisation and the way it conducts its business, being keenly aware of the fact that even the org chart can be flawed when it comes to genuine business roles. Many roles are split across business units. Take our Order Clerk - in the modern Gristle and Flint organisation there are many Order Clerks spread around the business, some for the web channel, some for telephone sales and some for the retail outlets. This made sense for the CEO, Charles “Chip” Flint (sorry), at the last reorganisation because he wanted accountability by sales channel and the ability to apply different levels of focus to each depending on his business strategy. He never said he wanted the Order Clerk software wheel to be reinvented three times though.

The luxury of technology is that it doesn’t have to split by the physical distribution of its users. Each channel Order Clerk (that Charles Flint prefers to call VP of Sales) should be using the same services unless the operational characteristics are fundamentally different, because then it’s SOA. In fact we could even go so far as to call the unit of code that provides the service the Order Clerk, so that each VP will totally get what it does for them.

A few months ago I was talking to a recently-appointed CIO about the pitfalls of SOA (he’d inherited an unusually expensive and horrendously incompetent SOA programme that had delivered nothing of any value in two years) and he said that the blessing and the curse of being in IT is that it’s like being locked in the basement of a house and being able to see the wiring and the plumbing of the whole building and yet almost impossible to get the marketing guys in the kitchen to realise that they share it all with the finance guys in the bathroom.

This is why SOA is both simple and rather difficult to achieve (and prey to the machinations of consultant gobbledegook) because the model it’s based on may not even be instantly recognisable to the business, let alone IT. But that shouldn’t stop us trying. Like any technical endeavour, it’s unlikely to be perfect first time, but it will get better and as it begins to work it will gain its own credibility and buy-in, which is always the best way to get things done.

Footnote

I’m indebted to Neil Wilkinson, an Enterprise Architect at Data Systems & Solutions for originating much of the role and document based thoughts in this article and for inventing a rather neat parlour game to help define what a role, a document and a service look like (perhaps more of which another day), and to Tim Franklin, an Enterprise Architect at EDS, for illuminating debates on this ever since.