SOA in Context

SOA does not exist in isolation. Whilst it may be the centre of the universe for SOA aficionados, SOA is just part of a "bigger picture". That isn't to say that SOA can be marginalized. Far from it, as SOA is an important part of, and enabler of that bigger picture as the image below illustrates.

Service Provisioning Contracts - New SOA Training

SOA is fundamentally a contract-based approach. The concept of ‘loose coupling’ works because the dependency between implementations is replaced by a dependency on contracts. As long as the contract between provider and consumer is met, then the dependency on a specific implementation is removed. However, the devil is always as ever in the detail. What contracts are actually required? How are they documented? How should the level of precision required be conveyed?

To answer these questions, I recently completed work on building, and subsequently delivering, a new SOA training workshop based on our concepts of Service Provisioning Contracts.

This workshop considers the following three prime contracts used in the provisioning of a Service, and the relationships between the,

• Service Level Agreement: The quality of service contract between service provider and consumer for the operational delivery of the service at run-time.
• Service Specification: The implementation independent behavioral contract between the service provider and consumer, and also the service provider and service implementer, that specifies what a service does but not how it does it.
• Automation Unit Specification: The requirements contract between the service provider and service implementer for the Automation Unit that provides the implementation of one or more service specifications.

Several CBDI Journal Reports Now Freely Available for Download

As well as making the CBDI Journal free from September onwards, we have also published several reports from past journals available for free download. Registration is required (but at no costs)

See the CBDI Journal index

Hope you find these useful.

How Long is a Piece of String? The 'Dark Arts' of SOA Project Management

We are often asked "how long is a piece of string?" Well that's not entirely true, more likely the question would be something more SOA related such as "can you tell us how long it will take to define a service architecture?" However, without some greater precision of what is actually involved it is equally hard to answer either question.

Portfolio Management and SOA

In the current economic climate, most IT organizations are faced with extremely tight budgets. Yet at the same time, the business is likely to be exploring new opportunities for growth or improvements in efficiency that in turn often increase the demand on IT. Application Modernization for example is not just a simple case of switching old systems off to immediately save money, but more often requires investment in order to improve efficiency of those systems and in the business processes they support in the long term.

You sense that for a long time it has been easier for organizations to take the easy option of giving projects the budget and freedom to do what they want, without regard to the needs of other projects or even the organization as a whole, as long as the project promises success.

However, enterprises of all types, especially the public sector, cannot simply dispense money like this anymore, and now must face up to making difficult decisions to reject project proposals that take such a ‘laissez-faire’ approach, and instead focus on more efficient utilization of the organization’s resources and to “do more with less’ by reducing waste and duplication, whilst increasing sharing and reuse

Consequently, more attention needs to be paid to the portfolio as a whole, rather than the projects in isolation

Service Portfolio Planning

CBDI Forum has long advocated a Portfolio Management approach to SOA, with Service Portfolio Planning (SPP) being a cornerstone of CBDI-SAE. So in a new report, as well as considering the specific case of SPP, I set out to consider other portfolio types and how to extend conventional portfolio management activities.

Service Portfolio Planning and Architecture for Cloud Services

The concept that Services are provided ‘somewhere in the cloud’ has always been central to our vision of SOA and we often used the cloud metaphor to illustrate this. Some 15 years ago in our early CBD research at Texas Instruments Software we presented the notion of application solutions assembled from a ‘cloud of services’ though this was positioned more as a way to achieve technology independence as the notions of a public infrastructure provided in the cloud were not well developed then.

The arrival of Web Services at the turn of the millennium provided a standardized mechanism by which location independence could be added and at that time we began presenting ideas like this, entitled "Does it matter where Services are Located?" - though in 2001 we will admit the audience was often more than slightly skeptical about the idea!

Does it matter where Services are Located?

Whilst there is now a high level of convergance throughout the industry on classification of Cloud Services as Software as a Service (SaaS) or Infrastructure as a Service (IaaS), as concepts such as Public, Private or Community Clouds, these generalized terms can be a bit misleading and vague when it comes to producing a more exact model of the Service Architecture. What exactly is the type of capability being offered by a Service? Who exactly is playing what role in the Service Supply Chain?

So, in the free report I have published in our CBDI Journal this month, I set out to show how our CBDI-SAE approach can be used and extended to architect for Cloud Services. The current guidance has been extended with new and refined classification systems, diagrams, policy types and techniques designed to promote visibility and good governance over Service Portfolio Planning activities and Cloud Services provisioning.  (see also the slideshare following the 'read more...')

Do's &Don'ts of Legacy Modernization - A conversation with Outsystems

I recently met with Maysoon Al-Hasso, at Outsystems to talk about how IT departments are addressing their legacy systems.

You can read our conversation in Maysoon's three blog entries

- Q.1 What are the top 3 things you've seen IT do to successfully address the competing demands of new build vs. legacy modernization when faced with limited or shrinking resources?

- Q.2 Is there a role for model-based tools like the Agile Platform in legacy modernization?

- Q.3 What are the top three mistakes people make when addressing their legacy?