What happened to SOA?

What constitutes innovation anyway? It isn't always obvious nor is it always a single thing.

In the 1960s, the engineers who pioneered the packet-switching technology that made the Advanced Research Projects Agency Network possible might not have thought they had done anything particularly revolutionary. They just built a new kind of networking technology to allow more flexible communications between computers than the older circuit-switching system could do.

By itself, packet switching was simply a different approach to something that already existed. But later developers added a tweak here, a standard protocol there, a new feature, a new capability, and over the course of about 30 years, they invented the Internet.

The path of innovation doesn't always follow the course it seems to be taking at first, said Don Rippert, chief technology officer at Accenture. But when it does change course, the result is often a natural evolution. As an example, he points to service-oriented architecture, an approach to enterprise architecture that creates interoperable services that can be used from various systems within an enterprise.

“I was disappointed by the uptake of service-oriented architecture, which I thought would be more pervasive today than it is,” he said. “It didn’t turn into the full-blown wave of change that I expected, particularly not inside the firewall.”

SOA didn't go away, though — it just took a turn. Much of what makes cloud computing and software as a service work today is that developers created technology using SOA standards. “It emerged in a different way than I thought,” Rippert said.

Now cloud computing “seems like a trend with a lot of staying power,” he added.

On the other hand, sometimes an emerging need leads to an innovative solution. In the world of database design, relational databases seemed like a simple and obvious solution for the transactional data that most organizations were storing. But several years ago, developers noticed that relational databases were not up to the task of sorting the unstructured data that was becoming increasingly prevalent.

In response to that need, a new idea in database design emerged. Broadly called NoSQL to indicate that they don’t rely on Structured Query Language, the databases are better suited to current needs.

Rippert said a database can be optimized for two of three things: consistency, availability and/or partition tolerance. Relational databases choose availability and consistency. The right choice for unstructured data is probably availability and partition tolerance. The latter trait makes it more scalable because it can work with databases that are physically split between multiple storage devices.

However, sacrificing consistency means that when new data is entered, it might be a moment before it’s spread throughout the database so that all users see the same thing.

“Most of the time, eventual consistency, which is measured in a second or so, is good enough,” Rippert said. “There’s nothing wrong with SQL, nothing wrong with a relational database, except there are now use cases where it doesn’t fit.”