Nick Randolph posted an interesting entry on The Right and Wrong way to Centralise Services. Firstly, I'd like to clarify the use of the word "Services". The referenced article is referring to the centralisation of IT systems and data so that regional health care units can share data efficiently. I don't believe Nick is referring to "Services" in the context of SOA.
Nick makes a very good point regarding assumptions that architects make when designing systems. It is the responsibility of an architect to design a system so that it will meet all its service level agreements. These SLAs must be met by the system even when things go wrong. It is of course important to determine that the SLAs are realistic in the first place.
Too many times have I seen systems designed for the best case scenario. I tend to find myself asking questions like, "what if this server crashes or is rebooted?". A common response to these questions is "that will never happen," closely followed by "why are you over complicating this?".
The complication comes from the nature of the requirements themselves. Systems that handle unreliable connections are more complex by nature. Burying our heads in the sand and hoping for the best will not deliver a system that does the job. Architects really must start thinking more about designing for the worst case scenario, such that the minimum SLAs are met.
To finish, I'd just like to thank Nick for the warm welcome to the blogosphere. Nick works for Intilecta and is very knowledgeable in the area of mobile applications. You can find out more about Nick's travels here.
Tuesday, February 19, 2008
Designing for the Worst Case Scenario
Subscribe to:
Post Comments (Atom)
3 comments:
Spot on! The reality is that requirements are complicated, systems do fail and that we need to architect for both the present and the future. It's interesting that you qualified my reference to services. Agreed in this context I wasn't referring to SOA style services. However, if you think of an occasionally connected application then at least two of the primary concerns, security and data synchronisation, are prime candidates for services and in fact can come from completely disparate systems.
An example of such services might use the new Microsoft Sync Services to provide your offline data, whilst the Client Application Services (which backs onto the ASP.NET Application Services) can provide role and profile management.
Doh! Somehow that comment got posted before I could enter my name....
I wouldn't consider synchronisation to be a candidate for a service in the context of SOA. Synchronisation would be an infrastructure utility that would be leveraged by one or more services internally. It is an implementation detail of a service.
Microsoft Sync Services is about moving data between distributed parts within a service, not about moving data between services. That is the role of the ESB.
I have a post coming up soon on service definition and service boundaries that will make this a bit clearer.
Security is an interesting one in the context of SOA and probably deserves its own post too. We want to have single sign on, which implies some kind of identity management platform. The process of issuing and managing the lifecycle of identities can certainly be seen as a service in the context of SOA.
However, Client Application Services simply provides a Web services interface into a user/role store to be leveraged by smart client applications. To my understanding, this does not deliver a federated identity that can be leveraged in a single sign on capacity across a number of services in the enterprise.
As I understand it, Client Application Services provides authentication and authorisation for one single application. You sign into that one application and then get issued a token that can be used only within that application.
As such, this on its own would not constitute a service in the context of SOA either. It again is an implementation detail of a service. Specifically, it details how the service's users authenticate themselves.
Post a Comment