In a new post, Alex Cameron, an EDS Fellow, notes that most well-established products and services have what is called a "dominant design" methodology behind them. For example, in the vehicle manufacturing industry, "the enclosed steel body car is a classic dominant design." The innovative growth and experimentation stage for the industry has long passed, and most, if not all, auto manufacturers agree on a common design. This can also be applied to aircraft, motor cars, lamps, typewriters, and integrated circuits -- you see little, if any, deviation by maverick manufacturers.
This same evolution from fast-paced innovation to dominant design has been taking place within the software industry -- much of the design has coalesced around Unified Modeling Language (UML).
In the next phase of software evolution, Cameron suggests that the industry is coalescing around service oriented architecture as the dominant design for integrating systems together.
"The concept of services and loose coupling is the product of a high level of innovation in the area of software architectures. The past saw mainframe centric architectures, Client Server, N-Tier, Layered Architectures, EAI, BPM and many others; all innovations towards solving a common problem, that of developing and integrating software components to form an information system architecture. However, none of them could be called a dominant design, simply because none had a follow-on and distinct phase of process innovation. In the case of a Software Architecture we could see this as a rise in "standards" that are adopted to control its implementation."
Cameron adds that SOA has taken software design well beyond what previous models have achieved. "We are now seeing the emergence of SOA Governance, SOA Maturity models and the like - I can guarantee no one has heard of a Client-Server Governance Model or Maturity model!"
It makes sense to conclude SOA has reached the stage in which it is the dominant design model. Of course, there are also plenty of analysts and pundits declaring SOA to be somewhat of a failure. So everybody and nobody is implementing SOA. But think about it -- if vendors and practitioners want to standardize and enable interoperability between disparate applications, interfaces, and services, what's the alternative to SOA? How else would they be doing it?
______________________________________________________________________
Leave a comment