Simple Service Enterprise - part 2

Yesterday’s post was about Simple Service Enterprise, and showed the basics: to keep up with the growing diversity inside and outside your enterprise for getting the same functionality on different devices and platforms, you need an Integration layer (the red in the middle). Can’t argue with that, point-to-point integration is a neat quick and dirty solution for very small IT landscapes and doesn’t scale cost effectively

SOA attempted to do so via ESB, but there a few reasons why that failed:

SOA was largely interpreted as having to do with webservices, i.e. XML wrapped in SOAP envelopes. Basically that meant, given the immaturity of both, that every one for himself defined and built his own XML and SOAP. Loads of restrictions, no benefits at all
ESB was largely interpreted as a dumb bus that got served by all applications, who needed to speak the new language. In stead of facilitating, it was limiting applications. Doing so, it gave the illusion of a uniform IT at a very, very high price. It also severely impeded phasing out applications and moving in new ones, as every new application had to go through the same painstakingly expensive effort of complying with the ESB’s format
SOA for some strange reason enforced composite services: this meant offering functionality not in place, and conjuring that out of thin air. It highly complicated SOA, and commiting or rollbacking a composite service naturally posed a huge issue

What was good about SOA? The idea that you expose existing functionality in the back-end in a uniform way. Was that new or shocking? You know my answer to that question

Why do I call this Simple Service Enterprise? Because it is.

A business has processes.

These processes can be divided into process steps, the smallest transaction possible that can be committed and rolled back without biting your tongue.

These process steps can be translated into (and usually are) business functions in the IT back-end.

The business functions together form a module or program or whatever name you want to use, and those combined are called application – an application takes care of at least one process, usually more

So the smallest business transactions are process steps, and those are taken care of by IT business functions.

If you want to take those out of their comfort zone and expose them to other people and / or businesses, you can do that via services. You may call those services interfaces, integrations – whatever. They’re just exteriorised back-end IT functions

Functionally, whatever you expose, you are not going to change anything between back-end and which ever frontend. Not a bit nor byte – nothing. If the business wants additional functionality, a business process or process step will get changed, deleted or created. That in turn will lead to a changhed, deleted or newly created function of module / program in your back-end, and it will be just another IT business function slapped onto the existing pile

Hence the three little arrows in between Information layer and Integration layer: those are just applications exposing their functions in a form that’s most convenient and cost efficient to them. XML? Maybe, if that fits the definition. JSON? Same applies. EDIFACT? Silly example, yet same applies. iDoc? Same applies.

The Information layer only exposes full functionality to the Integration layer, so no one cares in what form that happens – as long as it’s as fast, cost-efficient and (re-)usable as can be

Then, let’s take a big step and meet our new friends right at the very top of the picture: people of all kinds in all possible locations and roles: employees, customers or consumers: paid people, paying people and all others.
Do those people care in which form those services get exposed? No. They’ll be looking at them via screens, in which applications will run which will present them with fields, and the business functionality content will be in those fields.
Does it matter in which programming language those applications are built? Sure. Take the easiest ones, the best, the simplest, the most cost efficient, those that allow you for the smartest and sexiest representation, the best ease-of-use, in short: those that give you the biggest UX at the smallest price

Java, .Net, Ruby on Rails, PHP, script, HTML, XML, whatever? Exactly – whatever

So then, who does care about the format in which these services are exposed? Well, it seems nobody does. So what are the requirements and limitations here then?

Bandwidth, because the services need to be exposed and thus transported from the back-end to somewhere else on this earth, and vice versa: the further away from the office and civilised world you get, the smaller the bandwidth
Fit, because most programming languages and platforms have a predefined taste, and even ready-built building blocks or components. The older the platforms
and programming languages, the more old-fashioned that taste is and the higher the chance that building blocks are present. The newer the platforms and programming languages, the smaller the variety as well as the chance that building blocks are present: old will ask you “Well what do you have to choose from and we’ll just pick one”, new will tell you: “Listen we only support format XYZ”
Location, because as with bandwidth,
the further away from the office and civilised world you get, the smaller the choice of infrastructure

Bandwidth will influence size of message, fit will influence form of message, location will influence transport protocol.

Whatever these will be, the functionality will not change because you’re still using the same services, nor will you have to change your architecture because the Integration layer will interchange information with the outside world

It is absolutely out of the question that a new device or programming language will affect your back-end in any way whatsoever. Next: why REST is a bad idea.

(Cross-posted @ Business or Pleasure? – why not both)

Post Views: 7