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
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
(Cross-posted @ Business or Pleasure? – why not both)
