Next on was John Whiteway who went solo with nothing more than a piece of paper, his wit and intellect – great talk with the catchy title “Enterprise Social Networking underpins Predictive Science Capability”! Honestly inspiring stuff!

Following this was hard, but Simon Thurman of Emerging Technology at Microsoft UK is a dab hand, giving us a brief history of Azure on one slide …

After more pizza and beer it was time to realise that … Architecture is Boring, or so someone said to Neil Wetherall of Astra Zeneca! He gave some compelling reasons why people say this and more importantly, what architects should do to change this view …

In partnership with Swivel Secure, the owners of PINsafe, a multifactor authentication solution inTHiNK has successfully delivered a solution to hosting PINsafe in the cloud opening the way to delivering bank grade authentication as a service at a price affordable to all.

inTHiNK has developed a fully standards based Security Token Service that sits in front of PINsafe allowing the service to engage in the exchange of SAML-based claims leveraging the core value of PINsafe’s guaranteed one-time code algorithm.

As shown in the diagram here, a trust relationship is created between a relying application, here it is an Azure hosted .NET web application, but it could exist anywhere, and the PINsafe Federation Service (the Security Token Service). On entering the application, the client is redirected to PINsafeFS where they are challenged to submit a valid username and pin through this services relationship with PINsafe itself.The client submits a user name and one time pin code and on successful validation are redirected back to the relying application with a valid SAML ticket that can be used by the relying application.

Once you hit this site you will be redirected to PINsafeFS and asked for a username and pin.

Type in the user name test and tab to the password.

A unique TURing string will now appear.

Type in the characters that appear at position 1,2,3 and 4 of this string into the password field.

Submit and you will be validated by PINsafe

Once validated, a set of claims about the user will be wrapped in a SAML token and passed back to the relying application.

Back on the relying application, this SAML token is unpacked and the claims are accessed which include the user name.

Simple!

PINsafeFS is now in beta and available to clients to work with. The next phase will see the delivery of a full featured self-service portal to allow relying applications to manage their identities and the claims they wish to store and use for their users.

PINsafeFS is full standards based and non-invasive using WS-* protocols and SAML tokens.

It’s with great delight to announce the arrival of two new inTHiNKers to the inTHiNK Associate network.

Bola Rotibi brings over 18 years IT experience and is a world renowned and respected Industry Analyst in ALM space.

Bola joins the inTHiNK network to help define and deliver first class advisory services right across the Application Lifecycle which we are seeking to launch early in 2011.

Richard Godfrey brings over 20 years experience is software development, having built some of the most powerful .NET and Windows Azure based solutions in recent times. He is a well known and respected Software Architect heralding from many years at Microsoft and Deloitte.

Richard joins the inTHiNK network to bolster our ability to deliver architectural services and solutions designs as well as taking these forward into implementation and delivery.

Cloud security is perhaps the number one topic when it comes to cloud computing and this is still definitely the case if you look like meetings like CloudCamp for example. So why then is there not more of a focus on it from the cloud vendors?

Although the list is useful, and I especially like number 7 raised in a security context, there are a couple of key points missing, that while they maybe covered in some subtext under these seven items I personally believe they should be raised to the top level. So here’s my additional set of security topics to raise with your vendor:

Internal threat management

As we all know too well (or should), one of the majority of security threats of traditional data centres comes from within, with the cloud you’re passing this issue on to someone else. So what are the internal threat management procedures of your cloud vendor? How do they safe guard your data from prying eyes? Sure, encryption and segregation are elements that help here, but what are the data centre processes themselves?

Portability/access

A real favourite topic out there that in many ways overtakes the issues of interoperability is that of portability. How do I safeguard my ability to move from one cloud to another? Once my data is in a cloud how easily (expensive, quickly) can I get it off again? Now add to this the question of secure and robust portability and this becomes a really interesting question to ask.

SLAs/Penalties

So if there is a breach of security what is the cloud vendors policy? Is this transparent? Made publically available? What sort of compensation could you expect? Free hours? SLAs are an obvious discussion point with cloud vendors but are seldom discussed in terms of security.

Security in Depth

This is one I particularly like and relates to internal threat management and processes but specifically to the development and creation of the cloud vendor’s infrastructure itself. Clearly clouds just don’t happen, someone has to build them and that means software engineering. Therefore a clear explanation of their cloud development processes should be clearly articulated at a software development level. This is one of the key lessons Microsoft has learnt over the years and one I know well.

So what other security questions would you want answered by your prospective cloud vendor?

It is really interesting when you look back on your blogs over the years and reflect on how your views have changed, and whether anything still remains true given what you know now. Over the past few months I’ve been researching the state of SOA today; well over a decade since .NET Web Services arrived on the scene and the term SOA first came to popular attention.

One blog I’ve referred to time and time again in talking about SOA is the one I wrote on SOA Anti-patterns back in 2005. I use these anti-patterns regularly when talking to people and had come to think that their value had never been more significant than they are today given the emergence of the so-called “cloud”. However, I had noticed that they resonated less well with those where SOA was being “successful”. It therefore came as quite a shock when I actually re-read the blog only to find that the core tenet on which these anti-patterns were based was actually proving to be itself one of the core anti-patterns of SOA and why in so many cases SOA has proved unsuccessful.

The anti-pattern was actually described in the opening section where I suggest that the decentralised nature of SOA “left unchecked” could lead to the occurrence of a number of the anti-patterns that I went on on to describe. Unwittingly, I had hit upon one of the core anti-patterns for SOA; the square-peg anti-pattern, it was just that at the time I didn’t realise it.

The square-peg anti-pattern

As I noted back in 2005, SOA is a “decentralised” pattern for integrating distributed systems, but what I didn’t realise at the time and where the true problem turns out to be, is that we insist on trying to fit SOA (the peg) into a “centralised” model of IT (the round hole). This is like holding the same poles of two magnets end to end, they repulse each other, we are simply trying to put two incompatible models of operation together as one.

From a centralised perspective of IT these anti-patterns make sense, but turn the problem on the head and they become less significant and maybe cease to exist. The reality of the problem turns out, not to be one of fitting a square peg into a round hole, but that there are simply no square holes!

For IT and let’s face it, for the really important part; the business, to really take advantage of SOA it needs to give up being the monopoly, it needs to decentralise and devolve control to the services themselves. The result is smaller IT, encapsulated within the service, focused almost entirely on delivering business value for that service, rather than having to pay a high tax to conform to the demands of a centralised IT function.

The three Cs!

So if this is the major problem, then why do it? Why not drop SOA and retain the centralised model for IT? Of course this is an option, but let’s look at it through the lens of the three Cs that Hammer and Champy raised in re-engineering the corporation:

Customers take charge

Competition intensifies

Change becomes constant

IT is subject to the same pressures and has to deliver the service that is required by the business. Your customer demands the ability to be more in control, dynamic, they have choice and increasingly have the potential to ‘shop elsewhere’. The competition from others who can provide the service, faster, cheaper and to order is increasing. The rate of change required by your customer grows daily and the need for IT to move from reactive to proactive and part of driving business.

Specialised Units of Business Capability

In looking at the trends within the business itself, one can see it is differentiating into often finer units of specialism. the benefit being, to take advantage of market leading innovation quicker, cheaper and at lower risk. IT needs to power these new capabilities, but can’t do so through a rigid model of centralised command and control. These new capabilities need to move fast, grow fast and evolve quickly in response to change. The IT needs to be as close to that business innovation as possible and be part of the solution rather than a problem that slows down their time to react.

The rise of the Central IS function?

So what now for IT? Is it the end of IT department? Well may be it is, as we know it today. Decentralisation is inevitable for Business as it is for IT, as the technology layers commoditise there is less need for many of the old functions of IT, but given all these moving parts, these increasing units of specialised business capabilities, the increasing number of sourcing choices for services of all shapes and sizes, it is clear that there is a need for:

co-ordination

governance

compliance

innovation management

These, then become the watch words for the future of the centralised IT function, but it is perhaps the name that needs a change, it is less about the technology but still about the information and management and certainly needs to nurture innovation and of course it’s all about the service.

I once had the chance to move over to Redmond to deliver architectural guidance for Azure with the patterns & practices group so you can imagine my interest in seeing what they managed to produce in my absence, despite it taking quite a while to get this out there.

Where to get it

Documentation:

Source code:

The Review

As a piece of “Achitectural” guidance I am to be convinced that this delivers on its promise. In what states to be the first in a series it, rather oddly, decides to focus on “Migration” as the first topic. Personally, I was expecting more of a architectural review of the platform itself taking into account architectural considerations of reliability, scalability, redundancy and security and the like. These, instead, are confined to a rather light-weight platform overview, that raises more questions than it answers, including several inaccuracies, that reads more like marketing literature than offering technical insight. This may be because it is assumed that the “what is Azure?” discussion has already been done to death, but I don’t agree. No one has really addressed the architectural considerations of the platform, providing a thorough explanation of how features have been implemented and on what their limitations are. Certainly, nothing exists, to the level required by architects facing real business and technical opposition to cloud adoption. This, in my opinion is a missed opportunity and something that is still required.

That said, this is couched as being “guidance” and therefore the fact that it seeks to investigate the process of “migration” should not make it any the less useful. However, in this regard too, it fails to really deliver what, in my opinion the architect requires. Rather than considering a wider range of ‘adoption’ scenarios, it chooses instead, a simple, straight forward migration scenario in the context of an enterprise that has no concerns over use of cloud services. The real issues architects face in convincing others of the value of cloud, and even in convincing themselves in order to champion the opportunity is therefore avoided. A broader look at migration approaches and patterns and how these apply in the context of Azure I think would have provided more value to the architect.

However, it is important to note that the guidance is not completely devoid of any architectural value and the “How much will it cost?” section is a pretty useful evaluation approach to considering the cost impact of design decisions. It also does a reasonable job at introducing the subject of lifecycle management, although this is rather over simplified, it is still useful in highlighting the requirement. But it is on the developer side where the guidance starts excel, providing hundreds of developer gems hidden through out the document, such as the effect of partition keys on table query performance and in identifying the differences between development and windows azure table storage, referencing a useful MSDN article on the subject. In valuable stuff, but hidden from view.

In fact, it is pretty clear why the scenario was chosen, this is not really about providing architectural guidance, but in providing a context for explaining how to implement claims-based identity on Azure. As a technical resource for providing practical developer guidance on implementing a Claims-Based Identity and Access Control using Active Directory with an Azure application, this guidance actually scores pretty high. This type of guidance is simply not available else where. The problem and shame is that all this architectural veneer, hides the fact that this delivers genuine and much needed technical value and further, that no one who needs it will actually find it.

All in all, this is a valuable and well written resource, but my concern is it’s misdirected and that it’s value wont be fully recognised unless the right audience find it and in its current format, this audience would find it hard to get past the first pages to find all the goodness inside. The need here is to liberate the value and consider re-delivery as a straightforward, honest, simple to follow, developer how to guide. In the mean time, if you want to try and implement claims-based identity on Azure than I’d recommend skipping straight to Phase 1: Getting to the Cloud or even straight to the source on codeplex.

The Verdict

Rating (as Architectural Guidance): 5 out of 10. There are gems, but they’re hidden.

Rating (as Developer “How to”): 7 out of 10. If reformatted as a developer guide I’d put it nearer a 9!