Service Orientated Architecture (SOA\WCF) explained and defined for Executives
Service Orientated Architecture
Service Orientated Architecture (SOA) is a big business buzzword tossed into conversations at board meetings and at executive briefings. At this level, however, SOA really refers to connecting disparate systems across application, department, corporate, and even industry boundaries. This is the “Big” SOA concept, and this is the realm of the enterprise architect, and the space of million dollar Service Bus applications, SAP systems and other wonderful products.
Unfortunately the fact still remains that a chain is a strong as its weakest link, if the systems hooked up to the top of the range Service Bus are not rock solid and can not be trusted to produce the correct results all the time, then the some of the true potential of the investment is lost. I call SOA at the application level “Little” SOA.
The path to “Big” SOA begins with a solid base and understanding of the SOA paradigm, the ideas presented in this hub will provide you with some of the tools you need to achieve this.
As executives struggle to understand SOA, and their businesses struggle to reap the rewards of their investment in a service-orientated approach, the importance of “Little” SOA is becoming lost in the marketing hype and scramble by vendors to sell you their version of service-orientation.
By building a solid “Little” SOA base, the platform is set at an enterprise level to realize the composition and reuse that is the value proposition of SOA as a paradigm, as without a “Little” SOA that is properly portioned, rock solid and composeable, attempts to realize more will fail.
I hope to share some of the best practices, techniques and tools that I have learned from the last three years of constructing service orientated applications. In this hub I hope to provide clarify the terms and buzzwords in a jargon free way to assist business people in deciphering what there IT people are saying.
In future hubs i will add the jargon and provide an insight to application architects on how to construct “Little” SOA applications that achieve the non functional specifications that many projects only play lip service to. We will also explore the pieces need to construct, test and maintain such a business architecture
SOA, So What
Service Orientated Architecture (SOA) has become a well-known and somewhat confusing acronym; if one asks two people to define SOA one is likely to receive two very different, possibly conflicting, answers.
Some would describe SOA as a IT infrastructure methodology for business enablement, others would describe it as a way of creating efficient IT systems.
A Microsoft paper on SOA makes reference to the SOA Elephant, they use the John Godfrey Saxe’s poem about the blind men and the elephant. I find this to be an accurate assessment of the current state of confusion surrounding service-orientation (SO) within the business and IT communities; everyone describes the elephant a bit differently because they are influenced by their individual experiences.
"A wise man explains to them:
All of you are right. The reason every one
of you is telling it differently is because each one of you touched the
different part of the elephant. So, actually the elephant has all the
features you mentioned."
I believe that the confusion stems in part from the immaturity of the IT industry, who are always looking for the next silver bullet, and scramble of vendors to sell middle-ware. You cannot buy a SOA, if a vendor ever tries to sell you such a thing, run away
SOA can be thought of as a way of organizing your business and the capabilities it exposes with an emphasis on reducing duplication and the pulling down of organizational silos.
You could say:
• Service Orientated Architecture
(SOA) is an Enterprise Architecture Style
• SOA is not a methodology it is an approach or mindset usually called a paradigm
• SOA needs a firm foundation or the enterprise will fail as every piece of the SOA should contribute.
• Service Orientated Application Design (SOAD) provides this foundation.
• SOA is both a business and IT architecture approach, whilst SOAD is an application design approach aligned with and supporting SOA.
SOA is a business thing not just a IT thing
not just a paradigm for the construction of software systems, but a way
of modelling businesses, Ulrich Homann explains it well by
suggesting that businesses pushed by globalization and competitive
forces, have evolved the classic linear supply chain model into a
complex value network of partners participating in a common business.
The business model behind Hubpages is essentially this, Amazon, eBay,
Google and Hubpages all collaborating to in a common business.
These networks are expanding to include additional services provided by an increasing number of partners: customers, the government, financial services organizations, and so forth. Investments in systems or applications need to take into account the requirements or opportunities enabled by this increasing interconnectedness.
price of this interconnectedness is integration, but there is a catch,
as we need to integrate with more and more partners, the technical debt we occur means that we will
never be able to catch up to the pace of change, let alone get ahead of
it. Business who pay catch up and struggle to change rapidly when needed
are rarely successful.
SOA is all about taking the capabilities of your business and exposing them for consumption, either internally or externally, in way that accommodates change. Think of it as future proofing your business.
Capabilities by nature are not IT artifacts, but business ones, business capabilities represent "What" your business does, not the "How" of the business. For example, Ship Product is a capability that most business would expose, that you can be sure that no two business follow the exact same process to get that product out the door. It is then important to understand that each capability is composed of a set of people, who action the process, the actual business process that is followed, and the IT artifacts needed to automate or execute that processes.
Identifying capabilities is the first step in moving to a SOA, of course there is a cost associated to exposing various capabilities, and capabilities should be prioritized according to the value they will bring to the business and possibly the competitive advantage that can be gained. I would say that these two criteria, business value and competitive advantage, can be used in deciding where to start your SOA journey.
Moving to a SOA is a strategic decision that
will affect the current structure of your business, it will effect the
people in your organization, the IT systems you build or buy, and how
the processes your business uses are run.
Business capabilities will provide a frame of reference to which to pose these questions and answer them for the various viewpoints in your business. It will help finds the stable elements of business to model your architecture around, and provide a conceptual layer that closely aligns to service-orientation. Service-orientation will supply the partitioned, but connected, structure to implement capabilities so that the IT that is implemented meets the actual business requirements and supports business agility.
- Building Service Orientated Architecture
SOA is simply to our current knowledge the best and most productive way to build software.
- Why your Service Orientated Architecture (SOA) needs to be like a VW Beetle
While driving to work one morning, I was behind an old Volkswagen (VW) Beetle, one of those originals form the 60s, proudly emblazoned on the back was the bumper sticker Old beetles never die.
The final word in designing SOA systems