Federated Identity Management in a Service Oriented World

Join me as I present to the Perth .NET Community of Practice on Federated Identity Management in a Service Oriented World. The session synopsis is below:

Gone are the good old days of siloed applications that identify users with a simple username/password combination stored in the application database. In today’s world of Internet based e-commerce where secure transactions occur over insecure open networks and in a service oriented world of composite applications where identity must be shared between systems hosted by different organisations on disparate platforms; in a world where increasing numbers of businesses are turning to hosting their applications in the cloud, and where users from partner organisations need to be securely granted access to enterprise resources, architects are turning to an ever increasingly complex array of security solutions to solve their identity woes.

How do we as mere mortals make sense of PKI, Kerberos, SAML, and a plethora of WS-* standards aimed at addressing these concerns? This session will provide a clear and practical description of how to apply today’s security technologies in order to effectively manage and share identity across applications, service and organisational boundaries.

Details below:

DATE: Thursday, September 4, 5:30pm
VENUE: Excom, Level 2, 23 Barrack Street, Perth
COST: Free. All Welcome

SOA and Platform Independence

Quite often I hear platform independence as not only a key benefit of SOA, but a defining characteristic. Let me begin by saying this is simply not the case. Platform independence in the context of SOA has two connotations:

1. Services can be hosted on any platform (Windows, Linux, .NET, Java, etc)
2. Services are interoperable regardless of the platforms on which they are hosted

Firstly, let us examine what a service is from a technical standpoint. A service is an autonomous coarse grained unit of logic which external parties can communicate by way of exchanging explicitly defined messages via its endpoints. The messages and endpoints are described by the service contract. Consumers must conform to policies stipulated by a service provider in order to consume the service.

Based on the above definition, any platform that can host a process that can exchange messages over a network is capable of hosting a service. This is not a miracle of SOA, it is simply the miracle of distributed computing which was around long before the emergence of SOA.

The second thing to note about the above definition is that it does not mandate any specific transport or encoding of messages. Messages do not have to be encoded in XML. They do not have to be transported over HTTP. Service contracts do not have to be specified in WSDL. Services do not have to be natively interoperable.

Now it is true that Web service technologies greatly improve service interoperability between platforms. But services in our SOA do not have to be Web services. Even Web services by today's definition do not mandate that messages are transported over HTTP. It is quite acceptable for a Web service to be exposed over a JMS or MSMQ transport. JMS and MSMQ are not natively interoperable.

It is also true that an intermediary such as an ESB can provide protocol translation which can make services that exchange messages with incompatible transports and encodings interoperable. But again, an ESB is not a prerequisite for SOA.

I guess the commonly held view that SOA and platform independence go hand in hand has emerged from the association between SOA and Web services. But once again just to set the record straight, SOA does not mandate platform independence.

SOA does however mandate that implementation details of a service are encapsulated behind the service contract. As such, SOA certainly makes platform independence easier to achieve. We just need to overcome any incompatibilities in message transport and encoding.

Business-IT Alignment

We hear the term (or should I call it buzz phrase?), business-IT alignment thrown around a lot these days - especially in SOA and Enterprise Architecture circles. In fact business-IT alignment is commonly named as one of the key benefits of SOA (along with business agility, which is something I'll discuss in more detail in a future post).

So what is business-IT alignment, and why is it important? What is all the fuss about? Simply put, business-IT alignment is the extent to which IT investments are made in accordance with business strategy. In the other direction, it is also the extent to which new technologies can be harnessed in order to gain competitive advantage. Furthermore, it is also the extent to which the enterprise IT architecture aligns with and supports the enterprise business architecture.

A model for business-IT alignment is illustrated below.

The elements of this model are:

Business Strategy

Johnson and Scholes in their book Exploring Corporate Strategy define strategy as "the direction and scope of an organisation over the long-term: which achieves advantage for the organisation through its configuration of resources within a challenging environment, to meet the needs of markets and to fulfil stakeholder expectations.

Expanding on this, a business strategy identifies:

• The long term strategic objectives of the business
• The markets in which the business should compete and the business functions required to do so
• The ways in which those business functions can be performed in such a way to gain competitive advantage
• The resources (people, skills, IP, technology, finance, etc) necessary in order to support the business functions and compete effectively
• The external/environmental factors that influence the business's ability to compete effectively
• The concerns, objectives and expectations of the various stakeholders (both internal and external) that have the power to influence the success of the business

IT Strategy

As with business strategy, IT strategy involves identifying the long term view of the IT function of the business. It identifies the direction and scope of the IT function over the long term in order to achieve advantage for the organisation through its configuration of IT resources within a challenging environment to meet the needs of the business and to fulfil stakeholder expectations.

Business Architecture

Business Architecture is the process of defining the business functions, processes, capabilities, services, roles and reporting relationships that make up a business. Here, we are referring to Business Architecture applied at the enterprise level, rather than the solution level.

IT Architecture

IT Architecture is often expressed as Information Architecture, Application Architecture and Technology Architecture. I'll describe these architecture domains in more detail in future posts. In short, IT Architecture is the process of organising IT and information assets to support the business architecture and IT strategy.

Businesses that have strong business-IT alignment tend to have the following in common:

• IT investments can be directly linked to specific strategic business objectives.
• The business drives all major IT initiatives in conjunction and cooperation with IT.
• The business has an explicitly defined IT strategy which is directly linked to the business strategy.
• IT is generally seen as an investment rather than an expense.
• IT has direct representation in the executive leadership team and as such is present during business planning and strategy sessions.

Most businesses today leverage IT only as a support mechanism. IT is viewed as a cost centre - a means to an end, rather than a strategy enabler. This is evidenced by the fact that many organisations do not have IT representation in the executive leadership team.

We see this commonly where the CFO belongs to the executive leadership team, and the CIO reports to the CFO. In some organisations, the IT function is buried even further down in the hierarchy. Business strategy is formulated without input from or support of IT. IT is then involved as late as possible in the process only as a means of executing business strategy, rather than being involved in its formulation.

As a result of this ethos, IT has little to no visibility of the business strategy. That is, IT has no visibility of the long term business plan or objectives. Consequently, IT is limited to adding value reactively rather than proactively. The IT function is directed to deliver systems with specific tactical scope, which although being part of a broader strategic vision doesn't give IT any visibility of that vision.

This results in the delivery of IT solutions that meet all the tactical requirements, but do not necessarily align with the long term strategic objectives of the organisation.

Furthermore, many organisations do not engage in Enterprise Business Architecture practices. As such, there is no enterprise-wide functional view of the business. Usually, there is only a structural view in the form of an organisation chart. We usually find various business processes that have been documented with varying levels of detail, scope and accuracy, but no view as to how those processes fit into the bigger picture or how those processes support the business strategy.

As such, IT does not have the necessary information in order to formulate an effective enterprise IT architecture. This only further forces IT down the road of acting tactically rather than strategically. If IT has no view of the enterprise business architecture, then it cannot structure its IT assets optimally so that IT systems have high cohesion and loose coupling.

A result of delivering IT systems with only a tactical focus over an extended period of time is an enterprise IT architecture that is an unstructured mess with duplication of functionality (often manifested as many applications performing similar functions across the enterprise), suboptimal distribution of data, data locked in application silos, large numbers of complex and brittle interdependencies between systems, and poor performance and reliability of business critical IT systems.

Consequently we see an ever increasing percentage of IT budget being spent on maintaining the status quo, rather than being spent on investing in new capabilities that deliver new value to the enterprise. Clearly this position is not sustainable in a competitive market.

One of the key ingredients in achieving business-IT alignment is an Enterprise Architecture program. Businesses are already seeing significant returns from this investment, and time is running out for businesses that have not yet commenced engaging in this practice.

How Many Services?

One of the questions I get asked rather frequently in my travels is how many services are appropriate in any given architecture? Well this is one of those unfortunate situations where the answer is, it depends. However there are some good rules of thumb that can lead you to determine whether you're on the right track in terms of defining your service model.

In the field, the number of services we see in any given enterprise tends to vary wildly. In some organisations there is only one service - the überservice. Other organisations have stated they have well over 10,000 services. But how good are these architectures? As I've previously stated just because an architecture is service oriented doesn't make it good.

We've discussed überservices before and they are clearly not a good thing. So we definitely want more than one service. But 10,000? How on earth did they achieve that figure? Well at the end of the day the number of services you'll end up with is largely determined by the granularity of your services. Fine grained services will result in more services than coarse grained services. We've discussed service granularity before too.

Ultimately the number of services you end up with will largely be determined by the flavour of SOA you pursue. If you take the JBOWS approach (not recommended), then you could end up with any number of services. You're building services in a completely uncontrolled way that doesn't conform to any particular architecture. Usually the longer you follow this path, the more services you'll end up with. Hopefully you stop before you reach 10,000.

If you go down the road of Service Oriented Integration then you'll end up with the same number of services as you have applications you are trying to integrate. If you have 400 applications in your enterprise, you'll end up with 400 services. Again, I wouldn't recommend this approach.

Layered service models have to take the prize in this competition. Due to the incredible fine granularity of services in this model you can literally end up with thousands of services! This is yet another reason why I wouldn't recommend this approach.

And finally we have self-contained process-centric service models. With this approach services are centred around process-centric cohesive business capabilities. The number of services you will end up with will depend on the overall complexity of your business model. But about 10-20 services is a good rule of thumb. Any more than 30 or 40 and I'd be raising the alarm bells.

Another thing to note is that the size of the organisation (in terms of staffing levels) is not a major factor in determining the appropriate number of services. The number of services will grow as the complexity of the business model grows. Keep in mind though that sometimes the complexity of the business must grow in order to cater for increased staffing levels.

Consumer Driven Contracts

A while back a reader sent me an email asking about consumer driven contracts and how they fit into my stance on SOA. I'd intended to share my thoughts on the approach with the rest of my readers but alas it slipped my mind. Better late than never though, so I thought I'd take the opportunity to discuss the concept now.

Consumer driven contracts as an approach is intended to provide inputs into the service provider's contract design to ensure relevance, as well as provide constraints on how a service provider's contract can evolve over time such that compatibility is maintained with consumers.

However the intention should always be that the service provider contract evolves in such a way as to better express the concepts of the provider. We don't want to reduce the semantic fidelity of communications with our services.

I would say that as long as you're sticking mainly to publish-subscribe messaging (that is, avoiding command messages), then the needs of the consumer are considerably less relevant. Consumers are only informed of events as they happen. Command messages produce a subtle form of coupling where the service consumer instructs the service provider what to do.

Services that publish events do not prescribe or assume what subscribed services will do (if anything) once a notification message is received. An event message describes only an event that occurred within a service. The subscribers should really have no influence on this. As such, they should not be influencing the schema of the event messages published by the service provider.

So when using publish-subscribe messaging, I would suggest that consumer contracts are useful only in providing constraints on what can be changed in the service provider's contract in order to maintain compatibility with its consumers.

That being said, service contracts tend to be quite stable with process-centric self-contained service models - so I've not personally found consumer driven contracts worth the effort.

Consumer driven contracts really come into their own with data-centric contracts and centralised data architectures. When we always need to go and get our data from elsewhere, and all our service consumers use that data for different purposes, consumers have a substantial dependency on the service provider's schema. They will likely need to influence the provider's schema quite regularly. That in turn will affect the other consumers.

This is yet another reason to pursue process-centric service contracts with decentralised data architectures. It keeps your service contracts stable by virtue of minimising dependencies between service providers and consumers. You can read more about service contract stability here.

The Service Oriented Car Wash

I recently had the pleasure of discovering that The Open Group have an SOA Working Group, the mission of which is "to develop and foster common understanding of SOA in order to facilitate alignment between the business and information technology communities." This is a very significant step in coming to a consensus on the definition of SOA in both the business and IT domains.

The group is putting together an SOA ontology, which will hopefully go a long way towards creating a standard definition for the main elements of SOA and their relationships to each other. The draft ontology in its current form makes reference to an example business scenario based on an imaginary car washing business. The scenario is outlined below.

"Joe has a one-man business. He stands on a street corner with a sponge, a bucket of water, and a sign saying "Car Wash $5". A customer drives up to him and asks him to wash the car. Joe asks the customer for five dollars. The customer gives him five dollars. Joe washes the car, then says, "That's all done now," and the customer drives away."

The Open Group at present states that this example identifies a single service, which embodies a single repeatable business activity performed by Joe - washing the car. The customer is identified as the service consumer. The customer "consumes" the service when he or she pays the five dollars for the car to be washed.

There are however some issues with this model. Firstly, the service identified in the model consists only of a single business activity. Services modelled this way are far too finely grained, thus resulting in low cohesion and high coupling between services. A business service represents an entire cohesive business function, which may contain many processes and activities.

Secondly, the service model completely omits the Sales function. Although we are looking at a one man business, there are two business functions here (each of which translate to a business service). There are two different processes at play here – Sell Car Wash, and Wash Car. The Sell Car Wash process involves two roles – the Customer and the Salesperson. The Wash Car process involves only one role – the Car Washer. Joe just happens to hold two roles – the Salesperson and Car Washer roles.

As the model as described by The Open Group consists only of one process, it is unclear as to whether their model follows an event driven paradigm. Modelling the business architecture around business services and events provides for a far more loosely coupled and maintainable business architecture than other approaches.

The example business scenario calls for a single end-to-end business process spanning two business services. This is best represented as two business processes separately defined, but connected via a single business event which we might call Sale Completed. This is the end event of the Sell Car Wash process and the begin event of the Wash Car process. This is illustrated in the EPC diagram below.


Modelling our services this way has our Car Wash service as a consumer of our Sales service. The customer is merely a participant in the Sales business service. He or she is not a service consumer.

Now although we could indeed model our business architecture as outlined by The Open Group, to do so would produce a Business Architecture with business processes spanning multiple business areas, thus having low cohesion. This would produce a more unstable business architecture description and provide a poorer footing for our IT architecture.