Service-oriented architecture (SOA) was once a topic hot enough to fill its own magazine. In fact, SOA was the first software development methodology to ever successfully pierce the realm of business management.

It was an endeavor that had to be undertaken not only with rigor but also with rigidity. There was One Way to accomplish SOA — or no way at all.

“For each activity we need to define: what needs to be done, how it should be done, who should do it, [and] how it should be measured,” said SOA Magazine as recently as October 2009. “The potential benefits of SOA may not be achieved without the enforcement rigor around development, deployment and operational management of services across the enterprise.”

Cue the Dragnet music. (In a moment, the results of that trial.)

Marching Orders

For some reason, despite how well rigid constraints and dogmatic principles of unbuckling loyalties have fared in the governing of nations since the Middle Ages, SOA wasn’t working.

Of course, said Gartner Research in 2011, it was because we were all doing it wrong.

As one Gartner analyst suggested then, perhaps if we made SOA governance into a kind of game (where the prize, I suppose, would be one’s salary) people would overlook the messy business of being forced to work like subroutines and compete for the glory.

It worked so well for the Romans for several hundred years, after all.

From the very beginning, the problem with SOA has not been with human beings but with their having dogma forcibly imprinted upon them. As a guiding principle of software development, SOA was about the notion that functions could be divided into discrete modules that behaved predictably and that yielded expected results. So you could define every module of software as a unit of service.

Not people, software.

In software, service orientation is evolving to a new form. It has to, in order to remain feasible in modern, cloud-based environments. What’s important is, it’s evolving in a way that people don’t.

Services are decomposing themselves into hundreds or thousands of tiny, self-contained, replicable entities called microservices. They’re doing this to make new forms of software, designed for execution in the cloud, scalable.

Agility vs. Agile

“If you think about how people have built applications in the past,” said Akana CTO Alistair Farquharson said during a recent webinar, “they have potentially moved to an agile development model.

But when it comes to actually deploying the application into infrastructure — whether it be dev or test or QA or production, it’s very much a waterfall process which requires a lot of time, a lot of effort, a lot of approval and a lot of people with their hands in the mix.”

Farquharson leads the technology effort for an organization that, until a few short weeks ago, was known as SOA Software. Now known as Akana, the company boasts that its platform "helps businesses accelerate digital transformation by securely extending their reach across multiple channels – mobile, cloud and Internet of Things."

The long-time CMSWire reader will recall whom we’re talking about: the producer of SOA governance systems for such environments as IBM WebSphere.

But the company is removing “SOA” from more than just its name.

As the CTO describes, SOA as a management philosophy morphed into such a contorted shape that it ended up preventing SOA, the development methodology. To emerge from this catastrophe, the former SOA Software had to poke the reset button.

“SOA became very vendor- and standards-driven,” said Farquharson. “That was never the intent.”

Service orientation as a concept should not be tied to any single middleware or service bus or protocol, the CTO continued. It should be technology agnostic.

“What happened was, many years ago, the vendors drove SOA down a particular path,” he went on. “And they gave us SOAP and enterprise service busses. And it’s a very, very heavy architecture, which is very contrary to microservices as they are today. Microservices are unabashedly anti-ESB. They are supposed to be lightweight, small, agile and easy to deploy.”

Indeed, Farquharson’s tale is borne out by history. While in 2004, SOA vendors were declaring middleware dead, by 2010, those same vendors (or the companies that acquired them) were declaring middleware. The same factor that led to middleware’s imminent death had promoted it to the emperor of the enterprise.

Agnosticism as a Virtue

Farquharson shares a tale of microservices as today’s software developers perceive them: devoid of any and all ties to dogma.

A microservice performs a very small, discrete function, usually on behalf of other software. It has an explicit interface — meaning, it accepts specific types of data and produces specific types.

It manages its own data store, rather than relying upon a database — anything it needs from a database is given to it at the time it’s instantiated (when it’s born).

Because microservices manage their own business, cloud orchestration systems can multiply them as necessary, whenever the need arises or when traffic spikes. They can then scale them back down when events temper down, so they manage their own load balancing.

So how does this change the management principles of major enterprises like yours? Well, that’s the thing ... It doesn’t.

At least, not directly.

By freeing software developers to devise functional services in smaller increments, enterprise platforms can evolve more organically and less monolithically.

Meanwhile, the rest of the organization should not pretend to be under any obligation to mimic the behavior of microservices.

“Why should businesses really care about microservices?” asked CTO Farquharson rhetorically.

“You get improved agility. Your development organization can move faster to deliver features. And this is partly as a result of DevOps, and partly of microservices. You are able to build smaller things faster than you can build bigger things, and deploy them faster. And you can also manage change.”