Advanced Concepts in Software as a Service / Service Oriented Architecture


Published on

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.

Published in: Technology, Business
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Advanced Concepts in Software as a Service / Service Oriented Architecture

  1. 1. SOFTWARE AS A SERVICE – FIRST THINGS FIRST Damon Wilder Carr, CTO agilefactor ‘A pattern language approach to empowering stakeholder communications’
  2. 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. 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. 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. 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. 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. 7. A meta model of the concepts ‘Blank Whiteboard’ Unconstrained Drivers
  8. 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. 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. 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. 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. 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. 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. 14. A meta model of the concepts – Real World Concerns
  15. 15. The Combined Dimensions
  16. 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. 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 Also See:
  18. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 31. THANK YOU!