#41-Agile Architecture-SOA AND SAAS

The way we create business automation in the modern environment has been influenced by the strength of various innovations that have preceded us.  This week I'll introduce this idea, and then over the next few episodes will examine some of the implications and opportunities.

Transcript

Technological advances can impact business agility in significant ways.  For example, when broadband internet connections became commonplace, it was suggested that large business systems could be created by connecting smaller systems to each other using the fast internet connections that all businesses enjoyed.  

This required strong, secure protocols to be invented, like SOAP and the WSDL standard as well as other innovations, but once this happened it led to very successful initiatives at places like Amazon, Microsoft, and Google to name but a few.  What came to be termed "Service-Oriented Architecture" led, in turn, to other revolutionary breakthroughs like cloud computing and massively parallel processing.  It's hard to adequately measure the impact this has had on commerce and the global economy.

Such was the extent of this success that it led some to conclude that not only should systems be built from component systems but that applications could and should be crafted in a similar way.  Thus, the notion of "Software as a Service” was born.

Most developers will tell you that modern software, for the most part, is made of other software.  The .Net framework, the Java virtual machine, Rails for Ruby, all of these products represent reusable frameworks that can speed up development, promote integration, and reduce defects.

But this is also a mindset, and it changes some of the expectations and assumptions that drive the decisions we make on a daily basis when creating business automation.

For example, when any valuable software is created today, it should be done so with the assumption that it may well be used later, by some other team for some purpose other than we intend today.  The old notion of "this is for internal use only" is out the window now. Not only is there no way to know that going forward, but it also completely ends the excuses some use to make for work that was not of the highest quality.

Also, in the relationship we call "client-service", we always consider "client" to be "clients", plural.  Even if there is only one client for a component today, we design for multiple ones because, at the end of the day, that is what is hoped.  That the work we do now will have even more value that we anticipated.

Finally, perhaps most importantly, it drives design decisions toward important principles, practices, and qualities that promote granular reuse going forward.  Put another way, SAAS has been extremely healthy for the development community because it pushes us in the right directions.

In the next few weeks, I will be examining some of good the things that emerge from this.  Stay tuned!