A domain-language driven approach to first understanding a common semantic set for shared understanding in SaaS/SOA. This is critical as these technologies enable new communications far beyond \'just the bits and bytes\'. Indeed people have to communicate as well before gains can be expected. This presentation covers the technical and organization concerns.

1. SOFTWARE AS A SERVICE – FIRST THINGS FIRST
Damon Wilder Carr, CTO agilefactor
‘A pattern language approach to empowering stakeholder communications’

2. Overview
 The problem with so many TLAs
An attempt to
 Even the SaaS acronym is commonly thought to be
eliminate the SOA. This is not necessarily true!
Industry Fluff
 The common sense bootstrap to SaaS
while not being
 Which is not so common…..
overly high-
level  A meta model view of the ‘Easy’
 The ‘Blank Whiteboard’ view
Concise  SaaS Expected Results
statements on  A meta model view of the ‘hard’
what you should
 The ‘Constrained yet Optimized’ Evolving State
demand for
SaaS business  Your Components have the GAC, what do your
services have?
driven value
 The Combined Dimensions
 Service Repository and Governance
 Common Feedback and Concerns

3. The problem with so many TLAs
The ‘Buzz’ Factor  I am using SaaS on purpose
 For some, SaaS means ‘external vendors who manage their services which
and those who you integrate with yours’
like confusion  For others, it means a philosophical approach in how you view the role of
software strategically and architecturally across all domains (this is the
Why a lack of view I am proposing we use, not SOA as ‘Software as a Service’ is
shared incredibly specific if we agree it is (grin)
understanding is  Our industry suffers from severe ambiguity in the core areas that
require clarity
now (and has
been) systemic to  Ask 10 technologists to define Service Oriented Architecture and
you’ll likely get 10 different answers
Software
Engineering  This encompasses not just SOA but its constituent parts such as
‘Domain Driven Design’ (and there are some who would argue my
statement that DDD is even a constituent.
Why we need to
 We have no ‘Webster's Dictionary’ that all have agreed to follow
resolve this  Therefore we can only do this at our organization. This is the pattern
internally language
 Everyone ends up being very confused and ‘stick’
 Before we can get stuck our goal is to avoid this predictable problem
by proactively understanding it

4. The common sense bootstrap to SaaS – Not so common actually
A lesson from the  The largest impact for Design Patterns are not
Gang of Four about code, UML Diagrams or technical
A statement of
details
immediate goals  What then?
related to a
common
 These are important but have less to do with why
understanding
this is so transformative to teams
 It’s all about the words.
A team that shares
 They create succinct and unambiguous language
a vision with the
business for teams to reach increased bandwidth,
stakeholders using however most technologist think in different terms
A COMMON  In one phrase (or even word) you can create a
language is definitive and concrete shared understanding of
incredibly powerful
a best practice for a very tangible item, across
business domains, practice areas, etc.

5. A Pattern Language as the Artifact of Shared Understanding
To address the
problems teams
face in
communication, we
use the term
‘pattern language’
to describe our
immediate
evolving solution

6. The common sense bootstrap to SaaS – Not so common actually
In technical areas like  If this presentation had one point, this is it:
SaaS that are ‘trendy’  We must create a clear and concise language and set of
and often ill-defined,
there are strong semantics (collectively called a Pattern Language) which
motivatig factors for attack all ambiguity and clarity in this often cloudy area
vendors, consultants,
etc. to MAKE THIS  The TLA ‘SOA’ is practically useless now so I use SaaS
MUCH HARDER THEN instead. Full definitions are of course key to this
IT IS
presentations and requested clarifications are expected
Not so long ago it
was very hard, but
 Stakeholders in SaaS cannot execute ‘actionable’ steps
now with the third- due to confusion on design, development, architecture, etc.
generation offerings related to a clear pattern language FIRST.
fully available SaaS
is not nearly as  OUR IMMEDIATE TO DO:
mystical.
 Produce a ‘Pattern Language’ (with easily accessed
But it is nearly references typically web based) for the SaaS space
impossible with (leveraging others work as well as our own, which is always
people/organizations evolving).
confusing everyone
with overloaded  We will achieve a level of immediacy and an elimination of
definitons ambiguity in what we mean when we communicate across all
levels of the enterprise (just like our services! – grin)

7. A meta model of the concepts
‘Blank Whiteboard’ Unconstrained Drivers

8. SaaS Expected Results
On occasion SaaS is
 Interoperate cross-platform in complex
providing more then is workflows with little to no effort or concern 
actually needed Key SaaS Differentiation
(especially in a phased
approach)  Dramatic End-State Reduction for Software
‘Overhead’ tasks  Most work becomes
We all need to be clear
exactly why all this strategic and benefits all systems
effort is being done.  Empower enterprise to achieve astounding
Almost all companies agility to address issues, large and small (with
benefit but benefits are IT as a true strategic asset, never a cost
ROI based
center)
 Ability to choose third-party technology
based on ‘fitness to need’ rather then
‘constraints of exiting systems’

9. SaaS Expected Results
 Short term ROI is impacted by additional effort, with
mid-long term ROI showing dramatic improvement
 Typically the largest ROI for non-SaaS is the initial release
of a new ‘application’ if it effectively solves the business
need (in its limited scope)
 With SaaS the concept of ‘Application’ is dramatically
changed, and rather then a first release always providing
the largest benefit, the ROI should increase for subsequent
release as they (more then not) will address a far broader
scope (more detail to come)

10. SaaS Expected Results
 Elimination of the ‘impedance mismatch’ between
the business experts and the software professionals
 CRITICAL POINT: The real provider of this benefit is now
almost always a precursor to an SaaS imitative. This is a
core enabler of SaaS (the Domain Driven Design with
supporting ‘component’ API) - more to come.
 This ‘Domain Driven Design’ precursor is now a given as the
two predominant SaaS APIs are now (finally) native
In addition to the other object-orientation and component lessons (WCF from
areas, these should be Microsoft and SCA from a Java Consortium) – We will not
in our thoughts as a get much into the implementation today I suspect
good measure (when we  Remember that success in SaaS interactions is quite
different then any traditional RPC or Distributed Object
are uncertain) about Framework. Although the new APIs allowing seamless
decisions. OO practices to build SaaS, remember this power can
‘empower you to fail’.
 We will cover specifics on that topic in great detail in
future discussions

11. SaaS Expected Results
SaaS is a  MEASURE: Most development – code even –
process, not a
single end-state becomes understandable by your most advanced
business analysts (or we are probably doing
The stages of something) – MUCH more to come
evolution to ‘get
to’ SaaS often  It is common to have a subgroup of the development
provide many team focus more on the infrastructural issues and a
of the same
benefits as SaaS
(typically larger) team to be far more business
itself facing (but this is not always the case)
 For example, the infrastructure team would develop a
The maturity
level of ‘when’
far deeper mastery of the enabling SaaS API typically
to evolve to the when compared to the more ‘SaaS Composite Delivery’
final stage is team. This term is more accurate then ‘Application’
non-trivial and
assumes a vast  As all core individuals driving solutions have created
level of a (ring a bell?) COMMON PATTERN LANGUAGE it
competencies becomes frictionless and all metrics are positively
across many
complex areas
impacted

12. SaaS Expected Results
 While your systems are ‘individual’ and ‘autonomous’
Probably the
as required, however they also are fully empowered
least understood to engage in collaboration with any other service
of the benefits
and the most  Example: A third-party CRM system which has an
entrenched role for the marketing department can
confused seamlessly participate in complex messaging workflows
across separate systems (regardless of platform) via
Is absolutely service interfaces
vital to SaaS  The finance department (which uses a Linux based internally
success developed system running J2EE) would like to build
predictive revenue models using the new algorithms created
by the recent PhD hire out of Columbia.
 These require detailed demographic information that only
exists in the CRM system. In addition we must extend their
proprietary browser interface (now showing its age) to not
perform well but not expose the user to any service
invocations. We must invoke services directly from the
browser using Ajax (a first for this application) to provide
acceptable performance

13. SaaS Expected Results
 All data must be real-time from ‘systems of record’
 As real-time data is processed and becomes aged, it will be
stored as Business Intelligence information in a SQL Server
2005 Analysis Services repository
 We want to leverage existing service interfaces and
implementations, with a key change: We want messaging to be
asynchronous and sent via our MQ Series environment – This
must leverage the same work but ‘inject’ the channel type via
external configuration
 Company executives will consume these as temporal graphs in
their Executive Portal – SharePoint 2007 MOSS’. Also, key
performance indicators which are derived from this OLAP
repository are calculated for monitoring status
 Here we have Asynchronous queued communication, real-time
high performance messaging and coordination

14. A meta model of the concepts – Real World Concerns

15. The Combined Dimensions

16. Your Components have the GAC, what do your services have?
For those who succeed  Service Repository
with SaaS, their success  Versioning is critical, and multiple contracts (same
can quickly become
their downfall. idea as a .NET component version which is strongly
signed) running concurrently is very common
Why? They number of
services are  This is a logical organization (usually top down) for
unmanageable, cataloging, finding and consuming your service assets
undiscoverable, and as well as much more (to be continued)
dependencies break left
and right. In short?  The number of services should explode over time, as
everything becomes a part in the larger whole.
It’s precisely the same
issues we had in COM, Without a repository you will find yourself unable to
and that the GAC use the SaaS Paradigm (by your very success in it!)
addresses (side by side
versioning for example
 If consumers cannot find what they need quickly and
is a critical capability in logically, the very core reasons for having services
SaaS) will often spin out of control.

17. Service Repository and Governance
 “Development organizations have found they must evolve new
compliance and incentive systems to ensure their SOAs are built on
stable foundations.”
 “Without governance, unfettered ad-hoc development of services
threatens to undermine the promised benefits of SOA, such as
improved productivity through service reuse and better alignment
with the business.”
 “Instead, SOA initiatives may lead organizations in a backwards
direction, pouring development dollars into a black hole. “
‘Weak governance haunts SOAs’, David Longworth
http://www.looselycoupled.com/stories/2005/gov-dev0606.html
Also See:
www.looselycoupled.com/opinion/2006/stanek-gov0517.html

18. Service Repository and Governance
Does that previous quote  Service Repository
sounds familiar? It sure  This is precisely what has killed most Object Oriented
does to me! reuse initiatives
Due to (I am guessing)  In spite of this rich history of failure, many are
the few companies who repeating it with reckless abandon
have reached this level
of maturity now, this is  It’s far better to ‘just get something running’ as your
a subject that is repository (say the UDDI Service in Windows 2003)
amazingly glossed over and evolve as required, as UDDI is the backbone of
far too often almost all candidate repositories.
What is an example?
 UDDI is now at Version 3.0 which Microsoft does not yet
UDDI is the most support
common (a free service  NOTE: When we have this problem we will not only
in Windows 2003) and be prepared, it will be a very nice indication of our
available (for years success
now) right is Visual
Studio.

19. Service Composition Strategy Guidance
 Service Composition as a Rule, not an Exception
 Most of the time you will combine services into composite
solutions
 It will matter little to you the technical details about the
services (such as platform, API, etc) as your interaction will
likely be purely as ‘just a set of class instances and types’
 A dedicated discussion will likely follow on just this point,
especially around
 Composite Security Contexts, Credentials, Single Sign-On,
Authentication, etc.
 Inter-Service Transactional Scope
 Inter-Server Workflow/Orchestration (especially now with easy to
use GUI tools)

20. Service Composition Strategy Guidance
 To succeed in SaaS you cannot avoid spending a lot of time
For a real composing services
measure of SaaS
 What are some guiding principles around this?
success, just see
 Service Characteristics that Help you Decide
how much you
 How much can a service be reused? If not a lot is there a better
are composing design or further decomposition to get more reuse – a constant
rather then question to ask yourself in SaaS.
building new  What is the type of logic that the service primarily performs? Just like
objects and the single responsibility rule, this loosely holds for your
services. lowest level services (as will be briefly discussed)
 Another view of reuse is ‘How could this service possible be used
As services are across other areas we are not thinking of’?
built and your  Every bit of effort becomes driven by these kind of thoughts, as your
benefit soon becomes far less effort to do very hard tasks. It’s a matter of
repository grows ‘I know we have most of what we need already, I need to search the
this should repository for a few items, but we can deliver this new capability soon. In
fact, this could also be leveraged by our marketing department as they
dominate your have a use case defined which we will end up covering 90% of. We will
development extend this to cover 100% and kill 2 birds.
 Hey, I just realized with these changes, this can become a service we can
efforts use in three more areas! We just freed up 20 hours of planned work!

21. Drivers for the ‘Three Service Composition’ categories
This work happens  To succeed in SaaS you cannot avoid
during your creation of spending a lot of time composing services
the Domain Driven API
which is a necessary
 What are some guiding principles around
precursor to full SaaS this?
(they actually happen in  Service Characteristics that Help you Decide
parallel typically, with  How much can a service be reused? If not a lot
shifting focuses) is there a better design or further decomposition
Remember these all to get more reuse – a constant question to ask
evolve via Agile yourself in SaaS.
iterations, a lot of  What is the type of logic that the service
feedback from the users, primarily performs? Just like objects and the
and quality checkpoints single responsibility rule, this loosely holds for
on all code via tangible your lowest level services (as will be briefly
items like Continuous discussed)
Integration

22. Drivers for the ‘Three Service Composition’ categories
 Another view of reuse is ‘How could this service
Want to start now on possibly be used across other areas we are not
something? Know that a thinking of’?
Mock Testing Framework
 Most effort is driven by these thoughts, as you
is necessary at some point experience less effort to do much more.
sooner rather then later.
 It’s a matter of ‘I know we have most of what we
Which tool? Try NMock2
need already and I need to search the repository
for a few items.
from ThoughWorks. Ask
me to pair-program with
 We can deliver this new capability leveraging
that much sooner now.
you to jump start this
 EXAMPLE: A complex cross-domain transactional
powerful technique.
service (use case defined) which we have reuse on
90% of.
NOTE: In our model, this
is the box called ‘Best
 The incremental 10% must be carefully
considered so the net benefit is far greater then
Practices’ in the lower the work would otherwise be.
half.
 In other words, almost all work (at least has the
potential) to be strategic, and all effort should be
considered in these terms, not ‘just get it done’

23. Task Services
 Task Services
This is an oversimplification
most likely, however these often  In many ways these can be though of as ‘use case’ driven as your
become the first ‘shared pattern
use cases will start ignoring your existing system boundaries
(otherwise why do all this!)
language’ words that are used in
the beginning  Another way to think of this is as a ‘Controller’ however that is not
recommended due to conflicts with patterns like MVC.
These are blatant rip-offs of the  Just getting use cases that ignore your boundaries will allow
Domain Driven world we will discovery of your services. This is typically a critical early driver
inhabit, and in fact, many of service definition from Business Analysts
decisions around these items are  They are the top level of the tree, and almost always call two or
made there. more lower level services
 These are the simplest form of orchestration, can serve as the
The areas which differ transaction coordinator, and the injector of specific capabilities
significantly are when we need into lower level services via configurations in the repository or
to do fundamental elsewhere
transformations due to a  ]This is almost always decomposed much further using whatever
necessary Entity API that simply makes sense for your enterprise
does not translate to a service  This also tends to link back to how you model your repository
(almost always because it is
from a vendor, as we have the  In short? These are very important (again depending on the
ability to avoid this)
pattern language and various design decisions)

24. Entity Services
Now is a good time
 Entity Services
to point out that we  This is NOT CRUD! Even without SaaS our work here is
are not addressing fundamentally object oriented. SaaS is MOSTLY object
ANYTHING to do oriented but not to the same extent.
with the user  Why? Services are very clear in their separation of
interface. Data and Process definition, unlike a class. However at
least this work is done via Interfaces instead of the
It is assumed that we previous requirement to build separate XML Schema
can support just definitions for contracts (more to come)
about anything
thrown at us.
 We are not simply wrapping rows in a table (with some
exceptions where they happen to match – probably
due to over normalization)
 By focusing on working out our Domain Driven Entity
API, we can now see why it is a precursor. Almost
without exception this will be leveraged by Entity
Services.


25. Entity Services
 Why not skip the Domain Driven API?
Almost without
exception today,  It turns out that solving those problems overlap
the ‘Best Practice’ extensively with the same problems (except cross-
used from the platform concerns for the most part)
service layer up  A Domain API is a ‘Best Practice’ for the code services
to the UI is the execute to fulfill their contracts
Model View  Often Entity Services are similar to the Entity Classes
Presenter Pattern
(to be discussed
(with a transformation into the Service Messaging
in detail) with Requirements)
Dependency  Most organizations will benefit immediately from the
Injection and Domain API so this is yet another way to
Inversion of  Create the CRITIAL feedback loop
Control (again,  Create the shared language between the Business and I.T.l
we will cover all
that later)  Seamless fit the process of ‘delivery highly visible value in
iterations as often as possible’.
 We gain immense value from the feedback of a ‘Pre-
SaaS’ Entity design that will directly impact and improve
SaaS work.

26. Entity Services
We will likely focus
 For example: If you do not need
extensive energy interoperability (at least not in the short
on the Domain term but likely will add it later) in a use case
Driven API which but do need maximum performance due to
will driven (mostly) real-time concerns, you will want the option to
the Entity Services leverage this Domain API.
Task Services come  Indeed this is THE SAME API that your services
when we have a use, they are just a layer wrapping them
base, and utility (basically)
services are often  In the real-world, no company always invokes
dynamically
injected
EVERY ASSET via SaaS or via a Domain API.
It’s always some point on a continuum. Rather
then ignore this, we embrace it!

27. Utility Services
 We have many ‘cross-cutting’ areas which all services will need
All the stuff you
 Security, Authentication, etc…
know you need to
do  Logging
 Audit Trail
Logging, Security,  Services dedicated to these areas can be called ‘Utility’ services
and any cross- or ‘Common’ services
cutting
 BEST PRACTICE: As will be demonstrated, we recommend
infrastructural Injecting these dependencies using an Inversion of Control
concern would go contain (like Castle Windsor)
here
 This is a huge win as this is a standard practice in any Domain
It is assumed we API development and even Object Oriented development
will leverage the  It is only recently with the advent of true OO APIs for SaaS that
best practice of an we can use the best practices learned in that space and apply
Inversion of them to the SaaS space. This is no accident, as vendors needed
Control container to lower the bar and leverage the expertise developers already
using Dependency had and let them apply it to SaaS.
Injection  This all used to be so much harder and less fun

28. Common Reactions….
 Can this all really be done?
 In short? ABSOLUTELY! Once things are as tangible as creating a
class, Interface, etc. that our in-line with our standards and Pattern
Language, it will likely become second nature.
 INCREMENTAL EVOLUTION
 many checkpoints that will reap rewards almost immediately
 CHANGING A CULTURE IS FAR HARDER THEN CHANGING TECHNOLOGY
 Although everyone is different there is now a clear evolution path set which
very clear stages and checkpoints
 It’s rare the team that succeeds in the face of overwhelming information
overload
 How are services ‘orchestrated’ by some coordinating entity? How
can we involve the business analysts in defining these orchestrations?
 How are atomic (transactional) operations handled across
fundamentally incompatible systems?

29. Common Reactions….
 How can a service possibly work with no change across ‘run-time’
injected details like the actual method of sending?
 In short? Our pattern language and design standards which will dictate
how to accomplish this with a little planning and the definition of common
practices our services will share
 After we have made significant progress on the Domain Driven API
Model (a step before we ‘jump in the deep end’ with SaaS), how
do we evolve this to a SaaS model?
 It just so happens you are now ‘killing two birds’ by evolving this way.
Again my previous comments discuss the possible downsides which we
address via our standards and pattern language.
 Let’s say we reach a latter stage milestone such as completing work
on our Domain API and we find we really do not need the
incremental next steps that SaaS provides?
 That is more common then most think. It’s a business decision, not a
technical one typically.

30. Common Reactions….
 What are the new skills as a developer I must learn to be effective
in this area?
 Now? Surprisingly few… Not long ago the burden was rather daunting in
many cases (WSE 3.0, XML Schemas, etc.)
 Exactly how are the messages you describe so different from the API
calls we make today or the distributed component calls I have used
before?
 This is one of the most important areas we will drill down on
 Can I really do work that is almost 100% business driven and ignore
so much of the nasty details of services? This used to be far more of
the work then any of the business logic!
 You’ll see (grin)
 How will my IDE (Visual Studio for example) help me work in this
new paradigm? Will I have to use other tools as well? How will I
even know I am building solutions that are in line with all this?

31. THANK YOU!