Service-Orientation, Service Oriented Architecture, web services, if you're
not using the word service you're just not cool!! :-)
As explained in my previous post I'm currently preparing to get SOA
certified and so it might be a good exercise for me to talk about
service-orientation and SOA in my own words. To keep it readable this will be
done in a series of articles, each focused on a specific topic.
Before I start the first article I want explain a naming convention. In a
lot of articles and books the term "SOA" is used while they are actually
talking about Service-Orientation (SO), SOA is actually part of SO. Mainly I'll
be talking about SO but to keep things simple I will also use "SOA" for both
definitions.
Introduction to SO(A)
SOA ≠ web services and you're not obliged to use web services to implement
SOA. Are web services the best way to technically implement SOA? I'm confident
to say yes but I do want to stress that web services are only the technical
implementation of a service-oriented design. To make it short, it's not because
you're using web services that you are doing SOA. Think of services as a
collection of capabilities focused on a certain topic, this topic could be a
business entity, a business process... (Invoice, Accounts Payable,...). In the
next article(s) I will talk in more detail about services, their design and
principles.
SOA is also not a pure technical idea, it doesn't only concern developers or
architects. It concerns the business of the enterprise, short (tactical) and
long (strategic) term goals, SOA can define how a WSDL will look like but it
also defines who has access to technical documentation of the service, SLA's
are also part of SOA. Don't think of a SOA implementation as a single
project within the company, each project should strive towards and contribute
to a global SOA within the enterprise.
SOA is about centralizing "logic", making it available through standardized
interfaces, managed by a centralized governance and has as purpose to deliver
strategic goals and benefits to the company.
Standardized interfaces are very important as it can lighten the integration
burden that exists in enterprises that use different development environments
(.net, java...) and different application vendors (SAP, Microsoft...). In the
case of web services these standardized interfaces will be WSDL for the service
contract, XML and XSD for type declaration and WS-* standards (policy,
reliability...).
The governance is responsible for how services are designed, developed,
published, versioned and for standardizing the internal process to deliver
those activities
Reaching SOA "utopia" is an evolution, most of the time you will start by
using web services to connect or integrate with different applications, then
service contracts will be more formally standardized, as the service inventory
grows the need for governance over this will become mandatory to successfully
maintain, evolve and version the inventory. But it's not necessarily a natural
evolution, planning and preparation, such as an inventory blueprint, are needed
for a successful evolution.
Let's have a look at some of the goals of SOA...
- Increased Interoperability
By consistently applying service principles and design standards
(standardized contracts...) services are automatically interoperable. Because
of the interoperability, integration processes start to fade. Services can be
used and composed more naturally even if they were created by other
teams/projects or if they were created in the past.
- Increased Federation
This means that applications and resources are united/composed but still
maintain their autonomy and self governance. As with interoperability, the
application of principles and standards is needed to achieve this unity.
- Increased Vendor Diversification
By designing a neutral service oriented architecture (i.e. web services) an
organization has the possibility to choose the best products from different
vendors. This gives the options to extend, change or replace vendor
implementations without "destroying" the global architecture.
- Increased Business and Technology Alignment
To create the correct levels of abstraction and to determine service
candidates the deep involvement of business experts is mandatory to create
services that can withstand change and that can be recomposed if needed to
follow the business changes.
...and now the benefits...
- Increased Return on Investment
As isolated applications need to grow and evolve over time so does the
complexity and cost of managing the application. SOA advocates creating
agnostic services that can be (re-)used and composed for different purposes.
The initial creation of this piece of logic will have a greater cost compared
to the creation of a classic application but it will be better positioned as an
IT asset that will reduce the cost of change and evolution over time.
- Increased Agility
As the service inventory grows over time with more and more agnostic
services that don't belong to a certain application but are a real IT asset, IT
can adapt more quickly to changing or new business requirements.
- Reduced IT Burden
As the SOA infrastructure grows and matures IT can focus more on adding
value to the business and less on plumbing and integration. This will also
reduce redundancy, overhead, size and the operational cost of IT withing the
company and it increases efficiency and agility.
This was a little introduction into the what and why of SOA, the next
articles will go deeper into the design and principles of services.
Introduction
, for the full Certified Consultant track
you'll need these 4 books:
