• The concept of services - small, independent pieces of software that executed a single task for whatever program called upon them - was nothing new, having been in use in enterprise infrastructure since the 1980s.  What  SOA brought to the table was a vastly increased scope of use for these small units of functionali
• SOA aimed to solve these problems by shifting internal application development practice towards the creation of re-usable components called services.
• First, the company would make a comprehensive map of the actual functionalities they needed from their infrastructure - what were the tasks that all of these custom programs had been created to automate in the first place?  How did they relate?  What kinds of data formats and protocols had to interoperate?
• Next, the company would determine how each of these functionalities could be expressed not as a single application, but as a collection of services.
• SOA looked great on paper, when companies attempted to put it into action, they quickly ran into difficulties.  Most of the problems were caused by similar sets of naive assumptions about organizational behavior that were included in every top-down adoption plan
• Top Down SOA Wisdom: The SOA "Adoption Team" selects and purchases a proprietary SOA Governance product.  Development teams will then learn and use this product, both to re-design all existing systems and to design future projects. 
• Why It Doesn't Work: Massive expense combined with lack of developer input and vendor lock-in is a recipe for disaster.
• when SOA was the hottest buzzword around, these departments were under heavy pressure to put an SOA in place as soon as possible, and SOA vendors were more than happy to prey on these fears.  As a result, the first step in the SOA process for many companies was the purchase of a multi-million dollar SOA Governance Framework.  
• guarantees vendor lock-in.  While vendor lock-in is sometimes tolerated by companies in application server products, where the loop of interoperability is fairly closed, it has absolutely no place in an integration architecture.  It's hard enough to make accurate predictions about how your needs may shift in the future without having made a multi-million dollar commitment to a single company's roadmap.  SOA is about what YOUR organization needs - not what a vendor tells you that you need.
• developer adoption.  Your development team isn't sitting around waiting for the chance to implement SOA for you - in fact, in addition to their regular workload, they're probably also kept busy putting out the day to day fires that already plague your network.  The effort required to switch to a new model is not trivial on its own.  When coupled with a mandate from on high to use a new tool simply because that's what the company has purchased, the task can become insurmountable
•  SOA is a big change.  Making a huge initial investment in a single product is a sure-fire way to kick your entire organization into panic mode, when what you need is a clear, orderly plan that you can implement incrementally, with plenty of input from all arms of your organization
• Top Down SOA Wisdom: SOA means an organization-wide paradigm shift, and everyone's efforts rely on everyone else's.  Thus, the whole shift must happen simultaneously. 
• Why It Doesn't Work: The majority of organizations do not have the resources to drop everything and focus on SOA.  SOA that falls from the sky is a pipe dream - well-planned incremental adoption is not
• Top Down SOA Wisdom: The SOA Service Repository saves developers time by giving them re-usable components.  That's why teams must keep all the information in the repository up to date.
• Why It Doesn't Work: The point of SOA is to make development easier, not load developers down with menial tasks.  Your SOA solution should automate the cataloging of services.
• Top Down SOA Wisdom: The key to successful SOA is an organizational culture shift towards "virtuous" architecture decisions.
• Why It Doesn't Work: The key to successful SOA is a plan made up of clear, achievable goal sets with well-defined benefits.
• The focus should be on making things easier for everyone, not about virtuous architecture; on improving existing organizational structures and processes rather than wholesale re-engineering; on implementing pragmatic tools at the work-group level rather than crippling them with bloated multi-million dollar governance tools.  

16 more annotations...

• Applications integration (or enterprise application integration) is the sharing of processes and data among different applications in an enterprise.
• There are four different levels of applications integration.
• data integration is also required for successful applications integration. If an application can’t exchange and understand data from another application, inconsistencies can arise and business processes become less efficient. Data integration is achieved by either writing code that enables each application to understand data from other applications in the enterprise or by making use of an intermediate data format that can be interpreted by both sender and receiver applications. The latter approach is preferable over the former since it scales better as enterprise systems grow in size and complexity.
• Without effective communication, business processes and data cannot be properly integrated. Depending on an enterprise’s particular needs, communication can be either synchronous, asynchronous, or some combination of the two.
• synchronous communication, a sender application sends a request to a receiver application and must wait for a reply before it can continue with its processing. This pattern is typically used in scenarios where data requests need to be coordinated in a sequential manner.
• asynchronous communication, a sender application sends a message to a receiver application and continues its processing before receiving a response. In other words, the sender application does not depend on the receiver application to complete its processing. If multiple applications are being integrated in such a fashion, the sender application can complete its processing even if other subprocesses have not finished processing.
• When designing applications integration solutions, asynchronous communication offers a number of advantages over synchronous communication, especially when it comes to services in SOA. In synchronous communication patterns, timeouts are more common when an application has to wait for responses from several other applications. This means that the availability of services increases since individual processes are not blocked out as frequently due to waiting on other subprocesses to complete. Subprocesses can in fact be executed in any order. Moreover, asynchronous communication allows for the loose coupling of applications, eliminating the need for connection management. This results in an applications integration solution that is more flexible, agile, and scalable - essential attributes for today’s enterprise systems

5 more annotations...

• SOA Is Still Mission Critical

  What can we learn from this?  A few things:
  • SOA isn't dead - it's more relevant than ever. 
  • SOA works - top down SOA adoption does not.
  • It's time for an SOA strategy that can be successfully implemented  - without the massive ROI risk and naive drop-everything adoption model.
• Implementing SOA means solving two sets of problems - technical problems related to the actual architecture, and strategic problems, which describe the day-to-day process by which the SOA plan will be carried out.
• In traditional SOA solutions, these complex functionalities are usually all handled by a central "broker" server.  All messages are then be passed to this single server, which is responsible for every aspect of integration.
• First, a broker model creates a new single point of failure, and then gives it in the most mission critical role in the entire infrastructure.  If the broker becomes overloaded (which is not hard, given that it must handle the entire integration and routing process for every message sent on the network), the entire infrastructure loses the ability to communicate.  Clustering could eliminate this problem, but it is difficult, because duplicating that much complexity is an expensive proposition (not to mention the high per-CPU license fees charged by most proprietary vendors).
• Second, using one central server to handle communication between all other network creates a far from ideal situation for organizations whose networks are spread across a large geographical area.  To avoid latency, these organizations must spend additional time and money developing a method of federating their network into geographical zones, once again duplicating all of the complexity of the broker hub, not to mention the increased cost of bandwidth.
• In response to the failures of the broker model , a new architecture emerged - the Enterprise Service Bus, or ESB.
• Enterprise Service Bus architecture allows the de-coupling of various integration components and basing their integration capabilities on open standards, rather than closed proprietary formats.   These changes provide a number of advantages:
  • No single point of failure - integration work is distributed across the infrastructure
  • bottlenecks in specific parts of the integration flow can be eliminated by clustering only these components, instead of duplicating the entire hub to solve a single problem
  • Modularity gives you the ability to use an integration "platform" model, rather than an integration "provider" model in your SOA - your integration architecture only needs to be as complex as your scenario demands, allowing much more agile, tailor-made solutions
  • Support for open standards, such as JMS, XML, JCA, and JBI ensures interoperability while allowing for insight and input into future development
• As we discussed in the introduction to this article, as many as 80% of top-down SOA initiatives fail.  Top down SOA advocates often dismiss these statistics by leveling blame at the organization, rather than the failed top-down approach. 

  Generally, these statements center around a critique of the organization's "culture" - that the organization in question did not successfully execute a shift to "virtuous" SOA-friendly methods.

6 more annotations...

• In a simple IT approach the focus is always on the on going evolution of the IT estate in line with business strategy and not based on a single project delivery. The way IT is set up tends to focus on the The Ivory Tower of Implementation Optimism v Long term viability which drives against simplicity and towards complexity.

  
  

  So the focus of simple IT is to value

  Long term evolution over short term expediency

  Architectural clarity over coding efficiency

  Business Strategy over IT strategy

  Simple IT is also to

  Drive IT costs in-line with their business value

  Drive IT technology selection in-line with the business value

  Create clear upgrade boundaries between different business value areas

  Manage IT based on the different business value areas
• The point here is that simple IT is not actually about making a single project faster, its about making the 2nd project and its support faster and more efficient. This means having control and direction into which the right approaches can be used, Agile where its about value creation and reaction, package where its about standardisation and SaaS where its about utility.

• The SOA value system is paraphrased below as:  

   

   
  1. Business Value. Technology for its own sake should be avoided.
   
  2. Strategic Goals. You can't really talk about SOA if you aren't looking at the big picture.
   
  3. Intrinsic Interoperability. There's this notion of 'intrinsic interoperability' that needs to be achieved.
   
  4. Shared Services. Services are to be designed to be shared (note that reuse is not the termed used here).
  5. Flexibility is preferred over optimization (typical trade off is flexibility versus efficiency).
   
  6. Evolutionary Refinement. SOA doesn't attempt to boil the ocean and an incremental approach is preferred

• guiding principles. Here's a quick take for each of the principles: 

   

   Respect the social and power structure of  the organization. - Sounds like being mindful of Conway's Law.  
  
   Recognize that SOA ultimately demands  change on many levels. - If you can't convince everyone, then you could fail. This statement seems to run counter to the idea of evolutionary refinement. 
  
   The scope of SOA adoption can vary. Keep  efforts manageable
  and within meaningful  boundaries. - Look for low hanging fruit and quick wins to show success. 
  
   Products and standards alone will neither  give you SOA nor apply
  the service  orientation paradigm for you. - Don't just buy technology, hire consultants as well. 
  
   SOA can be realized through a variety of  technologies and standards. - Breaks the bonds completely from WS-*. 
  
   Establish a uniform set of enterprise  standards and policies based
  on industry,  de facto, and community standards. - Don't attempt to re-invent the wheel. 
  
   Pursue uniformity on the outside while  allowing diversity on the inside. - Some kind of notion of polymorphism and encapsulation going on here. 
  
   Identify services through collaboration with  business and
  technology stakeholders. - Don't design in a vacuum, get people involve. What about the consumers, do they have a voice? 
  
   Maximize service usage by considering the  current and
  future scope of utilization. - Plan for change. 
  
   Verify that services satisfy business  requirements and goals. - Get customer feedback. 
  
   Evolve services and their organization in  response to real use. - YAGNI principle. 
  
   Separate the different aspects of a system  that change at different rates. - Probably the more interesting guideline here. Usually, architecture layering is the approach here, however I am unclear if there are other mechanisms to do this. If this is to imply the notion of 'separation of concerns', then I'll be really disappointed.  
  
   Reduce implicit dependencies and publish  all external dependencies to increase  robustness and reduce the impact of change. - One of the better guidelines, a generalization of the idea of the utility of documenting or even exposing for machine consumption a services dependencies. 
  
   At every level of abstraction, organize each  service around a cohesive
  and manageable  unit of functionality. - A.K.A. Cohesion.   

• The paper lays out "Seven Principles of SOA Success". To summarizes the unamed author list these principles: 

   

   

   
  1. Minimize costs of disruption.
   
  2. Integrate incremenatally.
   
  3. Reduce coding.
   
  4. Use industry standards whenever possible.
   
  5. Accept the things you cannot change.
   
  6. Understand the strategic value.
   
  7. Buy - don't build.

• It's a pragmatic whitepaper that's worth a quick read. Too many integrations projects fail because of the desire for perfection. A drive towards perfections leads to idealism and creates vision that can easily become unrealistic. That is the crux of the problem, the person that can envision the ideal world is in many cases the person who cannot see reality.

   

   This reminds of an entry I wrote "Ten Fallacies of Software Analysis and Design". Where I outlined several intellectual sink holes which many developers are victim to: 

   

   

  1. You can trust everyone 
  2. Universal agreement is possible  
  3. A perfect model of the real world can be created 
  4. Change can be avoided 
  5. Time doesn't exist 
  6. Everyone can respond immediately 
  7. Concurrency can be abstracted away 
  8. Side effects and non-linearity should be removed 
  9. Systems can be proven to be correct 
  10. Implementation details can be hidden 

• I hereby present the 10 Commandments for SOA¹ Salvation: 

   

   

   
  1. Thou shalt not disrupt the legacy system.
   
  2. Thou shalt avoid massive overhauls. Honor incremental partial solutions instead.
   
  3. Thou shalt worship configuration over customization.
   
  4. Thou shalt not re-invent the wheel.
   
  5. Thou shalt not fix what is not broken.
   
  6. Thou shalt intercept or adapt rather than re-write.
   
  7. Thou shalt build federations before attempting any integration.
   
  8. Thou shalt prefer simple recovery over complex prevention.
   
  9. Thou shalt avoid gratuitously complex standards.
   
  10. Thou shalt create an architecture of participation. The social aspects of successful SOA tends to dominate the techinical aspects.

1 more annotation...

• transactions and SOA that is worth taking down: 

   

   (a) if you really, really need transactions - don't attempt to do it with Web Services. The CORBAs and the TPMs of this work do that stuff bettter than any amout of new fangled lets-do-it-with-angle-brackets ever will.
  
  (b) Do you really need transactions? There are times when yes, you absolutely do but equally there are times when you ended up needing transactions become of a function centric/object centric design model. Given that distributed transactions are hard and expensive (you cannot design away the network, you can hide it with dollar bills but you cannot design it away), it makes business sense to only use them when you need to.
  
  (c) Automatic rollback? Give me a break. 99% of business process rollback is business logic specific and is most cost effectively done by people who understand the context and can compensate much more intelligently than machines. If you have really simple compensation requirements then congratulations! You are in a minority in my experience.
  
  (d) Systems that have ACID semantics make perfectly good services to expose on an SOA. Like any paradigm, one of the skills of service decomposition is knowing when to stop. A temporal coupling boundary (such as a classic ACID) is a good place to stop. 

• Lean focuses on the elimination of waste in processes. Agile in comparison is tuned toward practices that adapt efficiently to change. There are though some commonalities between Lean and Agile Development. These specifically are: 

   

   
  • People centric approach 
  • Empowered teams 
  • Adaptive planning 
  • Continuous improvement

• The last two bullet points align directly with the SOA Manifesto. For reference:

   

   

   
  • Business value over technical strategy
  •  Strategic goals over project-specific benefits
  •  Intrinsic interoperability over custom integration
  •  Shared services over specific-purpose implementations
  •  Flexibility over optimization
  •  Evolutionary refinement over pursuit of initial perfection 

   

   

   Lean differs from Agile in that Lean is purported to be designed to scale (see: "Set-based concurrent engineering" and Scaling Lean and Agile Development ):

   

   One of the ideas in lean product development is the notion of set-based concurrent engineering: considering a solution as the intersection of a number of feasible parts, rather than iterating on a bunch of individual "point-based" solutions. This lets several groups work at the same time, as they converge on a solution. 

• In contrast, agile methods were meant for smaller more nimble development teams and projects. One would therefore think that in the context of enterprise wide SOA activities, Lean principles may offer greater value than the Agile practices. Well, let's see if we can convince ourselves of this by exploring this in more elaborate detail. 

   

   Lean Software Development is defined by a set of "seven lean principles" for software development: 

   

   

   
  1. Eliminate Waste - Spend time only on what adds real customer value.
   
  2. Create Knowledge - When you have tough problems, increase feedback.
   
  3. Defer Commitment - Keep your options open as long as practical, but no longer.
   
  4. Deliver Fast - Deliver value to customers as soon as they ask for it.
   
  5. Respect People - Let the people who add value use their full potential.
   
  6. Build Quality In - Don't try to tack on quality after the fact - build it in.
   
  7. Optimize the Whole - Beware of the temptation to optimize parts at the expense of the whole.

• Where can we find waste in the context of software development? Poppendieck has the following list: 

   

   
  • Overproduction = Extra Features.
   
  • In Process Inventory = Partially Done Work.
   
  • Extra Processing - Relearning.
   
  • Motion = Finding Information.
   
  • Defects = Defects Not Caught by Tests.
   
  • Waiting = Delays.
   
  • Transport = Handoffs.

• What steps in SOA development can we take to eliminate waste? Here's a proposed table: 

   

   

  Waste in Software Development	Lean SOA
  Extra Features	If there isn't a clear and present economic need for a Service then it should not be developed.
  Partially Done Work	Move to a integrated, tested, documented and deployable service rapidly.
  Relearning	Reuse Services. Employ a Pattern Language. Employ Social Networking techniques to enhance Organizational Learning.
  Finding Information	Have all SOA contracts documented and human testable on a shared CMS. Manage Service evolution.
  Defects Not Caught by Tests	Design Testable Service interfaces. Test driven integration.
  Delays	Development is usually not the bottleneck. Map the value stream to identify real organizational bottlenecks.
  Handoffs	Service developers work directly with Service consumers (i.e. developers, sysadmins, help desk)

• The customers for a Service are similar to the customers for an API. I wrote years ago about how the design and management of APIs leads to the development of damn good software. The same principles can be applied with the lean development of services. Taking some wisdom from that, here are some recommended practices for Lean SOA: 

   

    

    
  • Designing Services is a human factors problem.
    
  • Design Services to support an Architecture of Participation. Focus on "Organizational Learning"
    
  • Focus on what a user of your Service will experience. Simplicity is the #1 objective. Only when this has been accomplished (at least on paper) do we talk about implementation details.  
    
  • Services aren’t included in a release until they’re very simple to use.
     
  • In tradeoff situations, ease of use and quality win over feature count.
     
  • Useful subsets of standards are OK in the short term, but should be fully implemented in the longer term.
     
  • Continuous Integration - Fully automated build process and tests.
     
  • Always Beta - Each build is a release candidate; we expect it to work.
     
  • Community Involvement - Community needs to know what is going on to participate. Requires transparency.
     
  • Continuous Testing.
     
  • Collective Ownership.
     
  • Preserve Architectural Integrity -  Deliver on time, every time, but must preserve architectural integrity. Deliver quality with continuity.
     
  • Services First - When defining a new Service, there must be at least one client involved, preferably more.

• In conclusion, Lean SOA (A mashup of Lean and SOA) follow these principles: 

   

   

  Eliminate Waste - Spend time only on what adds business value.

   

  Create Knowledge - Disseminate and share Service knowledge with the organization and its partners.

   

  Defer Commitment - Be flexible before you optimize.

   

  Deliver Fast - Deliver value quickly and incrementally. Don't try to boil the ocean.

   

  Respect People - Let the people who add value use their full potential.

   

  Build Quality In - Don't try to tack on quality after the fact - build it in.

   

  Optimize the Whole - Strategic goals over project-specific benefits.

   

  Build Interoperability In - Services should be designed to be modular.  

   

  This is a simple as it gets. The devil of course is in the details.

5 more annotations...

• these patterns in building what he calls 'alsmost-infinite scalability'. 

   

   

   
  • Entities are uniquely identified - each entity which represents disjoint data (i.e. no overlap of data between entities) should have a unique key.
   
  • Multiple disjoint scopes of transactional serializability - in other words there are these 'entities' and that you cannot perform atomic transactions across these entities.
   
  • At-Least-Once messaging - that is an application must tolerate message retries and out-of-order arrival of messages.
   
  • Messages are adressed to entities - that is one can't abstract away from the business logic the existence of the unique keys for addresing entities. Addressing however is independent of location.
   
  • Entities manage conversational state per party - that is, to ensure idemptency an entity needs to remember that a message has been previously processed. Furthermore, in a world without atomic transactions, outcomes need to be 'negotiated' using some kind of workflow capability.
   
  • Alternate indexes cannot reside within a single scope of serializability - that is, one can't assume the indices or references to entities can be update atomically. There is the potential that these indices may become out of sync.
   
  • Messaging between Entities are Tentative - that is, entities need to accept some level of uncertainty and that messages that are sent are requests form commitment and may possibly be cancelled.
   

   

   

   These are interesting observations that jive quite well with my table of loosely coupled APIs, as well as my previous arguments about distributed transactions and the need for provisional information and contracts. I believe that these patterns can be implemented on top of ReST using in the manne

• Amazon, although I'm unaware of his influence on the development of S3, but it's interesting to contrast some of the design principles of that product: 

   

   

   
  •  Decentralization: Use fully decentralized techniques to remove scaling bottlenecks and single points of failure.
     
   
  •  Asynchrony: The system makes progress under all circumstances.
     
   
  •  Autonomy: The system is designed such that individual components can make decisions based on local information.
     
   
  •  Local responsibility: Each individual component is responsible for achieving its consistency; this is never the burden of its peers.
     
   
  •  Controlled concurrency: Operations are designed such that no or limited concurrency control is required.
     
   
  •  Failure tolerant: The system considers the failure of components to be a normal mode of operation, and continues operation with no or minimal interruption.
     
   
  •  Controlled parallelism: Abstractions used in the system are of such granularity that parallelism can be used to improve performance and robustness of recovery or the introduction of new nodes.
     
   
  •  Decompose into small well-understood building blocks: Do not try to provide a single service that does everything for every one, but instead build small components that can be used as building blocks for other services.
     
   
  •  Symmetry: Nodes in the system are identical in terms of functionality, and require no or minimal node-specific configuration to function.
     
   
  •  Simplicity: The system should be made as simple as possible (- but no simpler).
     
   

   

   

   There clearly is an emerging consensus on the architecture of 'almost-infinitely scalable' applications. Furthermore, revealing insights from the experiences of Google, Amazon, Yahoo and eBay are sheding a lot of light on this subject. 

• Although this is not REST, in practice there are many people out there who think "It uses a HTTP GET, therefore it's REST", even though it is calling a particular method, and also that it passes its parameters on the Query-String, not in the URI. One thing we've certainly noticed at Vordel is that there is a difference between "practical REST" (what people call REST, even though it isn't REST) and "pure REST" (actual REST). In some ways it is futile to rail against "practical REST" when faced with the "innovation, pragmatism and frequency of iteration" (William Vambenepe's words) of approaches such as Amazon's "Query API".
  

• Step 1: Strategy

  Your SOA governance strategy doesn't have to be a long and highly debated exercise, and it doesn't have to be 30 pages long. The idea is to prioritize the various benefits your organization perceives as important reasons to use SOA. Those priorities then drive the foundational principles for service design in building out your SOA. For example, which is more important to your organization: speed, reusability, or agility?

  • A strategy focused on speed may result in reduced reusability and agility, because it may not allow time to discover or build highly reusable services.
  • A strategy focused on reusability can have the opposite effect, slowing down your project methodology in order to allow time to better understand your service portfolio in order to build reusable services.
  • A strategy focused on agility is probably the most difficult to implement because it requires a sound architecture to ensure a speedy response to business processes changes.

• Step 2: Architecture

  In this context, architecture does not refer to physical or infrastructure architecture. This is not about how the BPEL engine talks to the enterprise service bus (ESB) or where the service registry would sit. This is more about your service meta-architecture or SOA reference architecture, which will define the taxonomies in the services you build and the services themselves. Again, this need not be a laborious task involving multiple architects debating in a room. A simple first step can be to agree on a clearly defined set of classifications that will distinguish your services. Here are a few guiding principles:

  1. The classifications have to be clear and distinguishable from each other. Think: how is a business service different from a proxy service? What is the difference between an orchestration service and a business service? If there are gray areas, rethink.
  2. Specify examples and design templates or patterns for each classification.
  3. Complete a draft portfolio of the service architecture based on your classifications. Remember, the theme here is practicality. Don't dwell on the architecture too long, If you reach an impasse, pick a best fit, and test it by moving on.

• Step 3: Method

  Many organizations I come across ask; What methodology should we use? What's the standard SOA methodology? What is a methodology?

  A methodology is a clear set of defined steps to take to achieve a goal. In other words, a process. In this case, it's the process for SOA. I don't know if we will ever have the standard SOA methodology. But you should consider the following three views when evaluating a service. You will need processes to handle each of these views, and they will be highly dependent on the strategy you have defined in Step 1.

  Services from a project view. How are services conceived and designed? If you focus on reusability or agility, is there more time allocated to service discovery and better service design?

  Services from a lifecycle view. Once services are deployed into production, are there methods for their continuous optimization? Do you consider rebuilding for better reuse? Do you consider service bundling for greater agility?

  Services from an enterprise view. This may be the most important of the three views. Refining the five steps in this article is just as important as the SOA project or the services themselves. This makes practical SOA governance possible. As you undertake more and more SOA projects, you will need to refine your architecture and improve your SOA methodology. But you will have a better service portfolio and therefore greater visibility for planning ahead.

• Step 4: Competency

  This step combats complacency. Once you have the processes around SOA-your methodology-you can identify the skills and roles required to ensure longevity in your SOA roadmap. This step is critical to protect against your SOA ace walking out on you to join a competitor. There are many roles involved in a SOA ecosystem. Proactively indentifying them and planning for training ensures that if your team really goes on a holiday and never returns, you have a competency framework for systematically filling the roles that are key to ensuring a successful SOA journey.

• Step 5: Technology

  Finally, you are ready to look at the tools you will need to improve your SOA journey. Obviously in SOA, you will need some sort of process engine-an ESB and various other components that make up what one would consider a SOA environment. However, with the previous four steps in mind, what is what is missing from your SOA setup? The following are important considerations:

  • A common governance repository that hosts your SOA reference architecture and all its defined artifacts. And I;m not just talking about a UDDI v3- compliant service registry. Do you have a relational repository that can index services and relevant artifacts and tell you which are owned by whom? Which business processes those services address? Which corporate strategy those services fulfill?
  • To increase agility you may want to consider automation. This means to execute or workflow some parts of your processes in the methodology in order to accelerate the lifecycle once it becomes stable
  • To maximize reusability, you may want to consider scripts, reports, or enablers to enhance the discoverability of the services. And I don't mean a search engine that gives you the service name and its Web Services Description Language (WSDL) location. You'll probably want to know a whole lot more about that service: its owner, its typical consumers, incoming and outgoing dependencies (what it consumes; what consumes it), and its classification and place in the SOA.
  • To increase speed, you may want to acquire best-fit reference models or prebuilt adapter sets. You can do this once you have a stable version of your architecture and your methology is comfortabley defined. You'll know what to look for.

3 more annotations...

• What Is SPML?
  SPML is an XML-based request response protocol that is used to integrate and interoperate service provisioning requests. The use of SPML is to enable organizations to set up interfaces for Web Services and applications quickly and securely. This is done by letting portals, application servers, and service centers generate provisioning requests in and across organizations.

  If you take a typical SOA security stack, SPML satisfies a complementary requirement for authentication, authorization and fine-grained access control. SPML is used for service provisioning whereas the authentication and authorization of data is done through SAML. Fine-grained XML access control is done through XACML.

• SOA Manifesto

    

    Service orientation is a paradigm that frames what you do.
  Service-oriented  architecture (SOA) is a type of architecture
  that results from applying service orientation.  

   

    We have been applying service orientation to help organizations
   consistently deliver sustainable business value, with increased agility
  and  cost effectiveness, in line with changing business needs.

• Through our work we have come to prioritize:  

    

   Business value over technical strategy 
  Strategic goals over project-specific benefits  
  Intrinsic interoperability over custom integration 
  Shared services over specific-purpose implementations 
  Flexibility over optimization 
  Evolutionary refinement over pursuit of initial perfection   

   

  That is, while we value the items on the right, we value the items on the left more. 

• Guiding Principles

      We follow these principles: 
  
   

   

   Respect the social and power structure of  the organization.  
  
   Recognize that SOA ultimately demands  change on many levels. 
  
   The scope of SOA adoption can vary. Keep  efforts manageable
  and within meaningful  boundaries. 
  
   Products and standards alone will neither  give you SOA nor apply
  the service  orientation paradigm for you.  
  
   SOA can be realized through a variety of  technologies and standards.  
  
   Establish a uniform set of enterprise  standards and policies based
  on industry,  de facto, and community standards.  
  
   Pursue uniformity on the outside while  allowing diversity on the inside.  
  
   Identify services through collaboration with  business and
  technology stakeholders.  
  
   Maximize service usage by considering the  current and
  future scope of utilization.  
  
   Verify that services satisfy business  requirements and goals.  
  
   Evolve services and their organization in  response to real use. 
  
   Separate the different aspects of a system  that change at different rates. 
  
   Reduce implicit dependencies and publish  all external dependencies to increase  robustness and reduce the impact of change.  
  
   At every level of abstraction, organize each  service around a cohesive
  and manageable  unit of functionality.  

1 more annotation...

• SOA is Dead; Long Live Services

• Successful SOA (i.e., application re-architecture) requires disruption to the status quo. SOA is not simply a matter of deploying new technology and building service interfaces to existing applications; it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates. The small select group of organizations that has seen spectacular gains from SOA did so by treating it as an agent of transformation. In each of these success stories, SOA was just one aspect of the transformation effort. And here’s the secret to success: SOA needs to be part of something bigger. If it isn’t, then you need to ask yourself why you’ve been doing it.

   

  The latest shiny new technology will not make things better. Incremental integration projects will not lead to significantly reduced costs and increased agility. If you want spectacular gains, then you need to make a spectacular commitment to change. Like Bechtel. It’s interesting that the Bechtel story doesn’t even use the term “SOA”—it just talks about services.