I was re-reading the Microsoft Architecture
Overview
by Michael Platt that’s up on
Architecture Center. It’s a
little old, but still very valuable. In the overview, Michael discusses
four perspectives on the enterprise architecture: business, application,
information, and technology which are commonly collectively referred to
as BAIT. (Note, I think it was Meta Group coined the term BAIT, but I’m
not sure. Whoever did come up with the term, I’m pretty sure that it
wasn’t MSFT). However, as we march forward building services, I wonder
if we need to regularly consider a couple of more perspectives.
I don’t think service-orientation dramatically affect business or
technology architecture. One of the big advantages of using web services
to implement your services is that you can reuse a lot of the web-based
technology infrastructure that companies spent the later part of the
nineties building out. Likewise, while services will enable
organizations to be agile and better achieve their business goals, I
don’t think it changes the actual goals significantly. However,
application and technology architecture change radically when moving
from an application-centric to a service-oriented approach.
When considering services, the application perspective is broadened to
include both applications and services. According to our conceptual
architecture,
an
application
implements a user interface while a
service
is a discrete unit of logic exposing a message-based interface. Even
though they are both typically written in code, I’m not sure lumping
them together is the right architectural approach. Building a single
service has many architectural similarities to building an application,
but an SO design also has to tackle the architecture as a
system-of-systems which the application-centric approach never had to
worry about.
Likewise, the information perspective currently covers data both inside
services (or apps – here the distinction is less important) and inside
messages. Obviously, the approach to data private to a service will
differ greatly from the approach to data inside messages. Things like
transactional integrity, immutability, extensibility and encapsulation
apply very differently to data and message architecture.
Each of the perspectives covers many different subtopics, so maybe
there’s no need to break services out from applications or messages out
from information. However, I’m on
record
stating that I think using services “represents a fundamental change to
the architecture model that the vast majority of systems running today
were built on”. Thus, I think that fundamental change should be surfaced
in language we use to describe the architecture, since language
influences thought. Granted, BSMAIT isn’t as cool an acronym as BAIT,
but it’s far more representative of the way the next generation of
systems are going to be architected.