Pivot: interacting with massive amounts of data

So I’ve seen all the flashy demo’s DeepZoom like the infamous Hard Rock Memorabilia site, but I must confess that I’ve often got stuck in the “nice technology, now where’s the problem” camp. Pivot from Microsoft Live Labs has fundamentally changed all that and it’s potential for business intelligence I think is fantastic.

Microsoft Live Labs Pivot

The video below is a little twee but it makes the point.

 


Get Microsoft Silverlight

What’s more is that Pivot is free and available Now!

Azure Architectural Guidance Part 1 Review: Migration

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:
Ff728592.pandp-logo-txt-2009(en-us,PandP.10).png

Source code:

image

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!

Visual Studio Architect Guidance

I got chance to organise an analyst briefing last week at Microsoft to cover the architecture capabilities of Visual Studio 2010. It was a great session as there’s such a strong and exciting story growing for Microsoft in their support not just for architects but right across the Application lifecycle that also reaches out to support development not just of .NET but other languages too which is a great example of Microsoft taking interoperability seriously.

There’s plenty I could talk about, such as UML support and more significant, that you can reverse engineer the likes of sequence diagram directly from your code. Or the architectural explorer and the support for creating layer diagrams with rules that you can then validate your code against plus the support for dependency matrices, and so the list goes on.

However, this raised a slight concern for me that with the growth in tools like these could eventually lead to a significant overhead in learning how to use them. Obviously they are built to be intuitive and easy to use but all the same, the shear volume could become overwhelming.

But as luck would have it the meeting coincided with the release of a codeplex project that provides guidance on how to get the best out of Microsoft’s Architect Tooling in Visual Studio. This has been produced by a set of Microsoft Rangers who have the job it provide out of band solutions for missing features or guidance on the product so you know it’s always going to be useful and based on real-world experiences.

Finally, as this guidance had input from Alan Wills, who has long been synonymous with the world of software modelling, I can’t recommend it highly enough. It’s worth downloading an evaluation copy of VS2010 Ultimate and having a trail if you haven’t already upgraded!

Architect Tooling:
vsarchitectureguide.codeplex.com/

Visual Studio Ultimate:
www.microsoft.com/visualstudio/en-us/products/2010-editions/ultimate

The Pig, The Banker and the Cloud

A story of cloud awareness

This is the story of the Banker and the Pig. It is not based on any specific single reality but on the collection of many factors. It’s based on the presentation I prepared called Unbundling the bank.

image

”Oh no!”, says the (fictional) Banker (not related to any actual banker I have met!) on seeing the initial slides from the Unbundling the Bank presentation.

“We live in a multi-sourced, software+service (Hybrid Cloud) world!”

”We just didn’t know it!”

”But hold on” 

”Isn’t SOA dead?”

”Didn’t SOA fail to deliver a return on investment (ROI)?”

“And anyway, we’re too silo’d and project and opportunity driven to consider adding cloud to the mix too!” the Banker concludes, almost looking a little relieved.

“Ah yes, but the problem isn’t with SOA it’s with the SOA Junkies!” says the Pig.

“The SOA Junkies?” shrieks the Banker!

“Yes” says the Pig calmly.

“They think too much like Adam Smith with his division of labour and Henry Ford with his assembly line! They’re too Task oriented!”

“They think in terms of the Separation of Concerns, abstractions, and ah … yes Re-Use, the magical holy grail of Re-use!” continues the Pig.

“How many times have we tried to deliver the ‘Single view of the Customer?’” asks the Pig rhetorically!

“These approaches just breed more complexity and like the forth bridge, never end, adding little if any business value as a consequence. All they do is pile on the technical debt from which IT slowly suffocates” remarks the Pig.

“The problem is that the approach is based on technology principles instead of the principles of business!”

“We need to look above the ‘HOW’; above the layers of people, process and especially the technology.”

“We need to focus on instead, on the ‘WHAT’ instead! We need to map the enterprise that describe its Business Capabilities. These encapsulate the people, process and technology, and unlike these things, capabilities are stable, unchanging, self-contained, measurable and above all value-oriented in relation to the business.”

“Oh!”, says the Banker!

What is an Enterprise?

“So let’s step back for a moment” says the Pig “and ask ourselves, what is the Enterprise?”

“Obviously, there are customers, one hopes! And then there are the Business partners, but what is actually inside that box we call the enterprise?”

The Banker is puzzled.

“Well I’ll tell you”, says the Pig, “It’s interesting, but from a capability perspective enterprises look remarkably similar to each other!”

“Ugh?” snorts the Banker.

“Looking at an enterprise’s capabilities at the top most level and we can see a regular pattern of capabilities that occur in all enterprises.”

“Firstly, there is a capability to plan new products and services.”

“Next, there is the capability to develop these new products or services”

“Third, there is create demand for these new products and services”

“And finally there is the need to Fulfil the delivery of these products and services. Simple, but amazing in the same way.” says the Pig with an air of triumph.

“All there is to an enterprise is simply Plan, Develop, Demand and Fulfil! Oh and add to this Collaborate too and that’s it; the 5 core capabilities that every enterprise or business has!”

“But hold on this can’t be all there is to it, surely!” questions a rather bemused looking Banker.

“Well of course not!” chuckles the Pig, “Each of these capabilities contains 1 to many sub-capabilities and these then contain more capabilities within them! So far we’ve taken capabilities down 5 levels and it still amazes me that this model holds true across the vast majority of enterprises we’ve seen!”

“Of course, there is variance, but there is about a 70% recurrence of these capabilities, even down to level 5, across enterprises, and across verticals!”

Silence.

“Ah how I love patterns” sighs the Pig looking upward as if to look for some hidden force.

The New Model Enterprise

“Ok, ok, so this is all very good” says the Banker, a little impatiently. “I can see that this is all very nice and pretty, but there’s devil in the details of those little capabilities!”

“There’s still the problem with the HOW!”

“Ah yes”, says the pig, nodding his head knowingly.

“Because these capabilities are stable, well defined and measurable, you can ask questions of them, value-oriented questions like, ‘what’s your value to the business?’ and ‘How healthy are you?’”.

“From the answers you get back you can produce a heat map of the enterprise that will give you a view of the health of your enterprise and more over where to focus your efforts in drilling down into the capabilities below, to find out what really is at fault and where to prioritise your efforts!”

“You can do this as a light-touch mapping across the enterprise and only drill down on the areas that flag up through the heat maps. Making it and efficient process”

“Ahhh” says the Banker, relaxing his facial expression slightly for the first time.

“But here’s the thing …” whispers the pig, leaning forward as if to ensure that this is for the Bankers ears only.

“Capabilities allow you to decompose the enterprise into discrete self contained units of specialisation, in so doing you can differentiate between the ones you care about; that creat value, and the ones you don’t.”

“You can then think about unbundling yourself from the cost of managing and maintaining these yourself.”

You can plan to move these away from a ‘bespoke’ internalised model to that of a more ‘standardised’ model.”

“Think of these capabilities as being like mini-enterprises all neat and self-governing and that the HOW might not need to be your problem at all” the Pig Winked.

“Oooh” says the Banker, his eyes widening, but this time less in shock and more in anticipation.

“Exactly”, says the Pig. “Now you’re looking at your enterprise differently aren’t you.”

“A suite of mini-enterprises doing stuff themselves, but collaborating to deliver a bigger result than they can do themselves. Some may even deliver their capability to another enterprise in time. This happens already if you consider the SaaS applications you are using today!”

“Furthermore, you can create new dynamic specialised capabilities and build them in the model of being a mini enterprise, able to persist on their own, without the layers of management that the models of the industrial era would and do enforce.”

“One day, like others before them, these once innovations, now commodity capabilities could be set free to find other consumers or markets and maintain their own innovation edge.”

“Now you have unlocked a new kind of strategy strategy; that of the New Model Enterprise (NME) based on Business Service Centric Principles!”

“And you can start to take advantage of the multi-sourced Software + Service (Hybrid Cloud) that you know we already live in.”

“Oh my!” gasps the Banker!

“Don’t believe me?” asks the Pig?

“Hmmm?” questions the Banker.

“Just go and ask the other banks …” said the Pig.

And with a nonchalant flick his tail, the Pig hoped off the Bankers head and returned to his glorious mud bath.

After all it really was the most splendid weather for the time of year!

The End.

 

Supporting Information

It’s interesting to note from Joe Mckendrick’s, SOA’s Dead, long Live Services blog that Gartner suggest SaaS doesn’t equal as much as 1% of enterprise IT Budget spend. But as Joe comments, the market seems healthy enough and it’s worth looking at some of Ray Wang’s numbers who reports that “SaaS vendors kept steady growth in the double digits”.

Unbundling the Bank @ CloudCamp

The other night I tried my hand at a 5 minute cloudcamp presentation which was mad and to be honest didn’t go according to plan! But hey I’ve put all that down to life-long-learning now and in probably talking to the wrong audience!

Below is the deck I presented and for some most baffling reason, that I can’t explain, the deck centres on a conversation between a very scared banker and a pig on his head!

 image

I came across it while hunting for images of banks and it made me really laugh at the time, but unfortunately I think it bombed a little on the day – no one (especially the OSS crowd) likes a guy from Microsoft trying to be funny – I had that feeling of the stand-up comedian confronted with silence once he’s delivered his best line! Urgh, the memory makes my skin crawl!

That said, I like the story and while the slides are great (of course;)!) I’ve had a go re-telling the story in a little more detail which I hope you’ll find fun and maybe even useful! You never know! This will follow as a separate post but in preparation here’s some background followed by the deck itself.

Some background

The title for the session came to me as you’ll know if you’re a regular to my blog, from the post I did the previous week that referenced an original post I did back in 2007 after seeing a session at QCon from Chris Swan and Craig Heimark. It came back to me a week or so ago when I got to talk to a group of around 30 Enterprise Architects for a large UK Bank. For too many the thought of using cloud was almost abhorrent and you could almost feel them each mouthing the words that “our bank will never use the cloud!”.

However, I had an ace up my sleeve being able to show, even back in 2008 through the work I did with Freeform Dynamics called IT on the front foot that Financial Services were among the leading adopters of Software as a Service (SaaS) at the time (remember the phrase cloud had not come to the fore at this time).

 image

But what was perhaps more interesting was that contrary to popular belief, SaaS adoption is far more significant where IT is seen as a strategic advantage to the business. Most, especially many of the SaaS vendors wrongly argue that it’s an opportunity for business to bypass IT and focus their efforts on that of converting the business executives, avoiding what in reality could be a quicker route through IT itself. It is clear that with the early adopters, success has very much depended on IT being involved and potentially driving the agenda. To support this, it is increasingly the case as you listen to early Cloud adopters from IT who talk of the need to convince the business of the benefits of cloud versus the risks.

image

The final graph from the report I used shows that in the majority of cases SaaS adoption only takes place where there is a commitment to Service Oriented Architecture (SOA)! This makes sense given the obvious concerns over storing data external to the organisation. An Enterprise that has a strategic position on Integration is clearly able to take advantage of the resultant hybrid model that must naturally follow.

image

 

The Slide Deck

View more presentations from Matt Deacon.

 

Next post will tell the story of The Pig, the Banker and the Cloud.

Unbundling the bank

Just over 2 years ago I first wrote the post entitled “unbundling the bank” and hear I am finding myself planning a talk at CloudCamp next week entitled the same! The title, I thought, came to me earlier this week when I had chance to visit a team of Enterprise Architects at a large UK bank. I was sure the title was not “original” and came from somewhere, so you can imagine my surprise when I did the necessary search and my blog came out on top – lol!

What I really love though – is that the thoughts are just the same, the evidence however continues to mount, pointing towards the further differentiation of IT, but increasingly of the business itself, from “centralised vertical models to decentralised models made up of “single value specialists”.

Unlike my talk to bankers back in 2007, this time, the EAs are thinking about the implications of cloud and software+Services more seriously, and while most would say never, to some the light bulb is on and the opportunity for disruption is imminent!

One thing I really liked and had forgotten about the talk by Craig Heimark back in 2007 is the drive to “create increased value to the consumer at the expense of the margins; the higher the volumes the lower the margin” which to my mind reads “commoditisation”.

In the old world view of innovation, it would make sense to keep this closed or hidden, to maintain ones market lead at the expense of competition. Thereby keeping margins high.However, in an open innovation model the race to commoditise is high, Keeping margins low to avoid competition and drive to mass market appeal and therefore scale quickly. If an innovation does not scale in terms of consumer appeal then it’s not an innovation worth pursuing.

Although, it takes time for shift to happen, there are examples all over of this taking place. Below is a list of common occurrences that may take place in isolation or combination but are enablers in moving towards a more “composite enterprise”. I’ve covered some of these previously so some repetition might arise.

Rise of Multi-sourcing

As discussed previously. Enterprises that have outsourced are actively re-insourcing, but in so doing they are differentiating between what comes in and what stays out. The latter are often non-differentiating or commodity, but by going through this process the results seldom remain with the encumbent outsourcer but move to new specialists.

Service Provider Convergence

The traditional models of software suppliers like system integrators, outsourcers and ISVs are converging. The SI is moving away from delivery of bespoke software to the delivery of bespoke services, software no longer lands inside the organisation’s datacentre but is automatically outsourced by the integrator. The integrator has a shared risk-reward with the customer – they are innovation partners with a desire to grow the market of the service itself, not just the value it itself fulfils.

Delivering Innovation as a business

Many enterprises are project-driven, but this is a mis-understanding, it is more that they are project-organised, they are in fact innovation or opportunity driven. The problem is they don’t realise this due to the project-based mentality that results. By taking an innovation-driven approach it is easier to see this as a business investment and to consider creating a structure that mimics more of a business than a project. this has dramatic and profound results both in terms of outcomes, but also to the people involved, the processes they create and the resultant capability that they generate.

Innovation Hubs

Closely related is the rise in innovation hubs or R&D centres, that incubate or provide support to new pilot innovations. This extends outside the enterprise too, to the service provider communities where a joint risk reward reduces up front costs of innovation in favour of longer term commitment and profit, leading to the model of collaborative innovation between partners.

Rise of the new COTS Service

A great example of the re-rise of COTS (Service) is the growth, adoption and subsequent mass-customisation of the large ERP systems over the late 90s and early 00s. For those that invested heavily, there is an increased growth in EA projects looking to detangle the enterprise from these investments in favour of the new COTS Services often delivered over the web as SaaS. The simple question being why customise what doesn’t differentiate? Furthermore, by taking a simplified ‘industry standard or accepted’ approach to a business problem you start to create the opportunity to chose who delivers the service over time.

The Cloud, the Enterprise Architect and the CIO

It was great to finally get a chance to speak at the IRM Enterprise Architect Conference Europe the other day. I’ve attended, submitted topics many times and this time around they gave me my big chance! I even got to speak in the keynote room as I’d had the most votes for that slot, so there were plenty of people to talk to which was great!

The presentation focused on four main areas:

  • Talking clouds
    Build a cloud taxonomy and an approach to using it with key stakeholders from business to IT.
  • Business Capabilities
    Discuss how looking above process and implementation at a business’s capabilities enables EAs to engage in different discussions about the business.
  • Future of IT
    The future IT department in terms of new responsibilities and roles and understand the key architectural considerations of entering into a world of hybrid architectures.
  • Lessons from Agile
    Finally, while EAs yearn to be heard by the business, it is too easy to isolate ourselves from the rest of IT along on the journey. We’ll look at key lessons from agile development and how these can be applied at the architectural tier and in so doing learn about “technical debt” and how in the right hands, it is a good thing!

Feedback was pretty good on twitter:

Chris Bird Old friends @taotwit, @Cybersal , @mattdeacon ,@aapthorp among others at #IRMEAC. New – too many to mention.Time with @alecsharp priceless
Chris Bird @mattdeacon me too. Liked your preso a lot, btw
Alec Sharp @mattdeacon Ah – I wondered if I’d got it right. Close, but no cigar. Thanks for taking my question on the cloud as an HR issue.
Alec Sharp  #IRMEAC @mattdeacon Looks at “technical debt” as a good thing when it helps deliver early, clarify needs, control investments, share resp
Alec Sharp  #IRMEAC @mattdeacon IT will physically contract therefore IT’s boundaries will expand.
Alec Sharp  #IRMEAC @mattdeacon So, it’s not the low-level utility stuff that is likely to move to the cloud, it’s the critical bits.
Alec Sharp  #IRMEAC @mattdeacon Nice bit of counterintuitive info – the more strategic the function, the more likely SaaS will be employed.
Kristof Dierckxsens  @alecsharp #IRMEAC @mattdeacon – What business does (its capabilities) is static – it’s the *how* (processes) that is more dynamic. << true
Alec Sharp  #IRMEAC @mattdeacon Some very good material here on what a capability is, and how it can be characterised in terms such as value.
Alec Sharp   #IRMEAC @mattdeacon – What a business does (its capabilities) is fairly static – it’s the *how* (processes) that is more dynamic.
Alec Sharp  #IRMEAC @mattdeacon Arrgghhh – my tweets about this promising presentation were lost because of a Network Timeout Error. A cloud problem?

So here’s the deck if you’re interested – thoughts as always welcomed:)!

Speaking at EAC Europe tomorrow

Looking forward to speaking at the Enterprise Architect Conference Europe tomorrow in London. Talking about implications of cloud – what else ;)! But also throwing in some tips from Agile too!

http://www.irmuk.co.uk/eac2010

Service Centricity

There is a shift happening but it’s been happening longer than many think and its effects may be larger and more significant than we at first expect.

This shift is business driven, as it strives to maintain its innovation edge ensuring that costs are reduced and ensuring it moves to a more lean and efficient model of operation. In truth , we can look back as far as Adam Smith and the division of labour in the 1700s to the origins of this shift and may therefore suggest that the shift is not really new at all. However, the old model and granularity of operations is under major pressure to change once more.

The shift is to one of Service Centricity and although it has been a long time in coming, the advancement in technology and the role of technology as an agent of change and business differentiator in the modern enterprise is rapidly moving us over the tipping point that causes us to re-evaluate the very foundations of “the enterprise” itself.

Hype and hot air!

Cloud is undoubtedly centre stage and the hype is reaching tsunami proportions. Many blame this on the vendors but while the idea has got the technology market excited I think this view deflects us from the real question of cause and effect. Is this an example of technology creating new markets or is it an example of technology reflecting the needs of existing markets? In essence it’s an element of both and as is often the case with new innovations it often causes us to view things differently which results in new ways of solving existing problems.

As such ‘Cloud’ in all its forms is set to a have a significant impact on the enterprise, but it is in delivering direct quantifiable business value that the cloud will deliver its most significant impact. If you think of cloud simply in terms of utility computing or dynamic provisioning of infrastructure then the point of cloud and its significance may pass you by.

I want your solution not your software

The impact of cloud is already visible across the enterprise today in the endemic use of Software as a Service (SaaS) Solutions at least somewhere within the enterprise and it is not that this is something that just happened overnight but has certainly been growing over the past 5 or so years. Many Independent Software Vendors (ISVs) cite that customers want but don’t want to burden IT. They ask if they can prototype the solution hosted by the ISV. The solution seldom ends up coming in house. One ISV recalled a customer saying “we want your solution, but we don’t want your software”. The issue for the ISV is that they are now a hoster and need infrastructure expertise, something they have little in-house skill or budget for. Cloud platforms provide these ISVs with an instant, scalable, reliable solution that they themselves would be hard press to achieve and all at a price that scales with their customers.

The dilemma for Internal IT

For Internal IT this creates a problem if done without their knowledge and its incumbent on IT to be proactive in the establishment of external services rather than representing a obstacle which will only be seen as holding the enterprise back. Taking a lead on these fronts is where IT can achieve the best results, providing vendor selection services to streamline the process and actually becoming the agent of adoption promoting well governed use of services across the enterprise.

Rise of multi-sourcing

The impact of cloud is not exclusive to the ISV or Internal IT but to the very fabric of the traditional software supply chain.Today we readily recognise different roles and functions across the supply chain from ISVs, to System Integrators, Outsourcers to Offshoring but what happens to these discrete entities if we look to the deliver of services? They start to converge. If I deliver a solution as a service, then I am no longer disengaged from the customer post-sale, we’re tied together for as long as the provision the service. What of the System Integrator? The solution is no longer deployed on-premises for running in-house, but as with the ISV, it’s hosted by the SI. The relationship between consumer and supplier are tied together once more. And so it goes, an ISV looks more like an SI, an SI more like and ISV, they both are outsourcing because the solution never in-sourced. The enterprise is now no longer exclusively in-house or outsourced, but multi-sourced.

Collaborative/Shared Innovation

similar to open innovation through multi-sourcing the enterprise is seeking partnerships for the provision of business services. This is fine at the commodity level, but as one delves ever closer to core business services the need to tailor and personalise and more importantly, protect IP becomes more significant. However, here too we see developments in service centricity through the development of innovation centres and incubation hubs often maintained by the enterprise itself. This works well but is limited and often expensive to nurture. By collaborating and sharing innovation more pro-actively with service partners it is possible to drive the innovation faster, cheaper through a shared risk/reward model, thus allowing the innovation the opportunity to expand much further beyond the horizons of the parental organisation as the market opportunity evolves.

Integration as a Service

 

Today we see see the commodity functions of email and collaboration moving out of the enterprise at a dramatic rate. So what next? Mission critical? Core Functions? Maybe not, but by using cloud to extend or embellish these core functions and to connect and integrate with other service providers, business partners or different parts of the enterprise itself then adoption rates here too can be seen to be gathering pace.

The Business as a Service

When I think of this I am always reminded of Amazon’s Mechanical Turk which takes it’s name from an 18th century chess-playing machine that really hid a human chess master inside.This service provides human workflow services that are accessible through a web service (programmable API). If we look at the business as a set of collaborating capabilities then we can effectively define boundaries or APIs and describe what the capability does but not how it does it or who does it. This is service centricity business style. This is the “composite” business or business as a service.

Small is the new big.

None of this for you? Maybe not. But if it’s not for you then be sure it certainly is for someone and as is the way with disruptive innovation, it may come from a source much nearer home than you think. Take one person with good business domain knowledge,  take one developer, take one cloud and what have you got? A business service that is reliable, scalable and available to a world of consumers at a cost that they can all afford.

The Economics of Cloud Integration

I met up with an integration partner the other day and we talked about how cloud could impact their business. He talked about the typical integration project and that it was quite an investment for the customer.

  • Phase 1: Partner builds out integration solution
  • Phase 2: Initiates technical training for customer IT staff
  • Phase 3: Handover management of integration solution
  • Phase 4: Work on joint second wave project
  • Phase 5: Full handover to customer.

In talking about cloud he suggested that it wouldn’t make sense when dealing with a simple EAI scenario of integrating two in-house systems. Why would you consider going outside the firewall to achieve this integration? The partner thought not, but I’m not so sure and suggested that if I offered to run the service for say a few £100 a month with strong guarantees I think the customer would have to think about it seriously. This is after all what the AppFabric in Azure is all about! At the time my mind was simply focused on the operational savings, but in going back to the phased delivery model above, there were also skilling and software licensing costs that needed to be factored into the equation.

So let’s imagine the cost of this simple EAI project from a traditional integration project and a cloud service perspective.

Traditional integration   Cloud Service  
Initial Development Project £45,000 Initial Development Project (50% up front remainder deferred over 5 years) £22,500
Training (x 3 people) £15,000   £0
Assisted Development Project £25,000 50% up front with remained deferred over 5 years £12,500
Software costs £25,000   £0
Support & Maintenance/year (10%) £7,000 Development cost recovery (divided 5 years)
Support & Maintenance/year (10%)
Hosting support (10%)
£7,000
+ £7,000
+ £7,000
Internal operations expenditure (FTE @ 50%) £30,000   £0
Total Cost over 5 years £320,000   £140,000

In this scenario the customer saves around 60% costs over 5 years – why wouldn’t the customer be interested? Also, the partner earns an additional £35k over the 5 years too, plus they still retain a close relationship and ongoing revenue.

Ok, so the model is overly simplified and probably missing a 1,001 things but offers an indication of a more balanced economic and innovation based model that aligns much better to the customer’s needs than the old model of software delivery and maintenance. Besides the obvious savings what is far more powerful is the effect this has on cashflow over time …

image

Not only are the initial cost reduced and spread over the 5 years, but so too are the ongoing maintenance/management costs.