I’ve reached new heights and have been accepted (after much scrutiny it must be said) onto the agenda at the Enterprise Architect Conference in June! Here’s my fully vetted and grammatically corrected abstract for you to savour:)!
Implications of cloud computing for enterprise architects
The “Cloud” is everywhere these days with every CIO shouting “I want one of those!”; a bit like they did with SOA and we ended up with the dreaded ESB! With Cloud the promise of procuring services without the cost and hassle of IT staff is all too appealing for many! But wasn’t this one of the great promises of “outsourcing” and we all know where that’s ended up! The problem this time is in many dysfunctional organisations the motivation in moving to cloud is as a way to bypass IT – this can only be a recipe for disaster longer term. So how can IT get on the front foot? How can IT become part of the solution rather than the problem? Rather than sitting back and waiting to pick up the pieces or a new job? For many large organisations this is something they may recover from, but for many others it will be disastrous, just spreading the spaghetti beyond the perimeter of the organisation. With clouds the problems don’t go away and issues of security, data governance, service management, contingency planning, Integration and management quickly come to the surface. To further exacerbate this issue, cloud has no simple definition, encompassing pretty much everything these days, such that what cloud is to you can be quite different to what it is to me! However, this is not to say that cloud is just vapour, it offers many great benefits but should be viewed in a broader context of what the business is trying to achieve. In this session we will seek to provide guidance on preparing for cloud. We will build a cloud taxonomy and an approach to using with key stakeholders from business to IT. We will discuss how looking above process and implementation at business capabilities enables EAs to engage in different discussions about the business. We will then consider the future of the IT department in terms of new responsibilities and roles and understand the key architectural considerations of entering into a world of hybrid architectures. 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 what “technical debt” is and how,in the right hands, it is a good thing!
See you there and also note that IASA will be sponsors too:)!
 |
The 5th annual Microsoft Architect Insight Conference is now open for registration!
This year we’re moving back to the full 2-day, 3-track format of previous years but with the flexibility to choose whether to attend one or both days.
Day 1 will focus on Architecting Today: From Cost to Innovation
Day 2 will focus on Architecting Tomorrow: Implications of Cloud
There are a pile of cracking key notes (see some of our headliners below) and the breakouts will focus on the needs of the Enterprise, Solution and Infrastructure architect, on top we are planning a series of interactive tracks so we can delve deeper into the topics addressed in the main break outs!
– Iain Mortimer, Chief Architect, Merrill Lynch Bank of America
– Andy Hopkirk, Head of Projects and Programmes and Director e-GIF Programme, NCC
– David Sprott, CEO, Everware-CBDi International and Founder CBDi Forum
– Ivar Jacobson, Ivar Jacobson International
– Kim Cameron, Chief Architect of Identity and Distinguished Engineer, Microsoft Corp
– Steve Cook, Software Architect, Visual Studio Team System, Microsoft Corp |
Hope to see you there:)!
www.microsoft.com/uk/aic2010
Here are the slides used by Eoin Woods, Nick Rozanski and Chris Cooper-Bland at the UK IASA meeting the other week!
Discover Simple, Private Sharing at
Drop.io
“When’s a principle not a principle?” was what I muttered to the person next to me at the UK IASA meeting earlier this week. But I think I do “an anti-principle!”
About 30 people turned up at the Onalytica offices to enjoy pizza supplied by Microsoft and to take part in a great workshop on applying design principles led by Eoin Woods, Nick Rozanski and Chris Cooper-Bland. As part of the introduction Eoin went through a baker’s dozen well known and not-so well known system design principles that were used in subsequent the exercise:
- Minimise coupling
- Maximise Cohesion
- Minimise complexity
- Maximise genericity
- Hide Information
- Modularise implementations
- Structure using services
| - Design for concurrency
- Identify what varies and encapsulate it
- Keep dependencies acyclic
- Dependencies should reflect stability
- Make Stable elements abstract
- Define things once
|
Although I think that there is much merit in these principles, many are used implicitly in the design of systems, I worry that by stating explicitly and used as a rule there could be are serious side effects.
First, there seems to me much duplicity here, for example 1,2,5, 6, 7 and 9 I think could all reasonably refer to the same principle of “Encapsulate where applicable” [Matt Deacon 2010]. Out of all of these the Gang of Four version “Identify what varies and encapsulate it” is the best as at least it responds to my next and perhaps, bigger concern.
Second, by using principles, it may be possible to defer responsibility to a default state which can lead to a poor solution for a given context. It becomes too easy to defer to the principle over making the right choice for a given situation which can lead to issues such as over-engineering, increased complexity, increased maintenance or poor performance. It is my contention that the context in which a principle might ubiquitously apply is so small as to make the overhead of their use far too expensive.
Third, the definitions and explanations for these prinicples may be in themselves, confusing or misleading, or open to interpretation. As Nick said late on it is “essential to be clear and unambiguous in the definition of principles” if they are to be used. As examples, I found “Maximise genericity” confusing (not just in trying to say the word after a beer) – does it mean to take a standard design approach or to create one? “Hide information” was another, besides the horrible use of the word “Hide” the description suggested to “hide as many design decisions as possible” and although it probably referred to implementation details it could easily lead to misinterpretation. It concerns me that in order to make these things brief and consumable we lose some of the clarity and accuracy of what we mean to convey/
So having sat back and thought on all this for a while I have tried to articulate a “set of principles on using principles wisely”, or what I think I’ll call a set of Anti-Principles!
Don’t hide behind principles (aka the blanket principle). When introducing a principle it can be all too easy to assume that this applies in all cases. However, it is often the case that a principle only applies in certain contexts even within a single design. Assuming a blanket approach to context can significantly impact other key aspects of a system requirements and quality attributes. For example using the principle “Structure using services” has a innate impact on performance. This may prove significant or not dependent on the context, but by using a blanket principle who is to know?
Not all principles are good bedfellows. In choosing to take on a principle, it is important to consider the impact that this will have on other principles and design considerations or quality attributes. Designing for concurrency might achieve performance but impacts on complexity, structuring as services might modularise a design but impacts also on complexity and performance and may impact on being able to define things once. Principles are not independent and can create a design conflict in which often all principles suffer.
Principles doesn’t trump pragmatism (aka over-engineering through principles). A closely related outcome of both anti-principles above, is the introduction of unnecessary complexity through over-engineering. A blanket application of principles may lead to an overly complex solution in certain parts of a system where there is no current requirement for this to be the case. This is further exacerbated by the fact that the complexity at first glance appears to be practice but is in fact an over-engineering of the problem due to adhering to a principle.
To demonstrate these anti-principles let’s take the example from the workshop.
The functional model describes several modules and a large monolithic database (plus config database) that we assumed was shared across the modules. As best as one could tell the design appeared reasonably well “modularised” but it was thought that the data store might compromise “modularity” or “coupling”. to solve this it was suggested that the data might be broken up and the parts maintained within the module to which it applies, in so doing we’d conform to the “hide information” principle. However, concern was expressed that data may be required by multiple modules which might lead to compromising the “define things once” principle as private data may become duplicated. A natural conclusion would be to extract this data out to a separate ‘shared’ module. On one level the new design would appear an correct and appropriate but this now creates an additional layer of complexity not contained within the original design, nor dictated by any functional requirement of the solution as a whole.
It is not possible to say with certainty how to best resolve in this particular instance with the information available, but it does illustrate the need for pragmatism and flexibility when considering principles for a project and much more so when one considers laying down principles at an enterprise wide level.
I think there is much that can be learnt from the agile development in this respect and that rather than setting down principles and rules up front, an architecture needs to be more adaptive and refactoring more acceptable. Building software we all know is not like building buildings, it’s set in a context of uncertain requirements and in a medium of the virtual and abstract unconstrained by physics. Guidance through principles I would agree is valid, but these should not be viewed as laws, for if that is the case, they will be broken but this will be hidden. Far better that we challenge the default and if we carry ‘debt’ as a consequence, that ‘debt’ is known and can be managed.
The value of managing “Technical Debt” is another agile concept from which much benefit can be taken but that I’ll leave for another day.
Among the great many Christmas presents I received this year was the book Outliers by Malcolm Gladwell. In it he argues that success is as much about where we’re from and what we do as who we are and that even the genius needs a helping hand. While this might explain a lack of any meteoric rise in my case there were a several pieces that really struck a chord with me in relation to the world of software development.
The first was his definition of the three qualities for meaningful work:
- Autonomy
- Complexity
- Connection between effort and reward
You need an element of all three to render work meaningful and therefore satisfying, fulfilling and motivational. Remove or restrict any one and the equation becomes an imbalance. This reminded me of the central themes of Leading Geeks by Paul Glen, in terms of understanding what motivates and drives the “geek”. Too often in my experience the equation of meaningful work is at an imbalance within IT projects, but it has often not been clear to me which part of the equation is at fault.
Software projects, like air crashes it seems, are rarely the result of a single catastrophic error (like a wing falling off) but as a result of a series of individual failures (an average of 7 it appears) that themselves could easily be remedied, but when left and combine, impact to such an extent that a serious failure becomes inevitable. At the centre, most commonly are errors of “teamwork and communications”. Sounds like software development? It did to me.
In his almost eccentric style, Gladwell uses aviation safety as a vehicle to look at cultural imbalances both within a culture and across cultures that result in communication barriers that ultimately result in bad decision making. He explains how this was at the core of Korean Air’s appalling safety record in the 1990s (something he was at pains to explain has now been remedied!).
During the discourse Gladwell cites Hofstede’s Power Distance Index (PDI) that measures the extent to which the less powerful members of organisations and institutions accept and expect that power is distributed unequally. South Korea (60) has a much higher PDI than the USA (40) which was a significant contributor to the communication breakdown between the US flight controller and the cockpit and between members of the cockpit itself that led to the loss of Korean Air flight 801.
This made me reflect on the implications for software offshoring. If we compare the PDI for the UK and India for example we see a PDI of 35 and 77 respectively. This is a gap of 42 (meaning of life?), over twice the difference between the US and South Korea! Is it any wonder then, that studies like that from Accenture yield results such as 76% of the respondents identified that the difference in communication styles is often the reason for conflict in offshoring and outsourcing?
The solution for Korean Air was simple and effective and at the heart realised that it needed to take cultural heritage seriously and that cultural legacies are powerful, pervasive and persistent.
Clearly, by taking PDI seriously, there is immediately much we could do to improve the potential that offshoring offers above using it for simple “factory” style development tasks as is so often the case today. I am sure this is probably already the case in more forward thinking organisations and would be interested to hear about it.
However, what struck me more was when Gladwell explored the heritage of people from the southern highlands of Kentucky and described the ideas of KIPP schools (Knowledge is Power Program) for under-resourced communities throughout the US. You can take the boy out of “Harlan”, but you can’t take “Harlan” out of the boy it suggests. The point being that culture is persistent across generations and this firmly puts the question of cultural imbalance much closer to home! If we look around our organisation, the cultural mix is massive. Furthermore, if we look at how projects are typically organised it is incredibly easy to see that there is potential for cultural imbalance to occur. The knock on effect is an imbalance in meaningful work which manifests in poor teamwork and communications and ultimately poor project success.
Fundamentally, I would suggest that project failures are due almost entirely to an accumulation of relatively simple and solvable human-based errors that are left uncheck. At the heart of this is poor teamwork and communications. This is not that we don’t communicate, we do, often too much, in ways that obfuscate the real meaning of their intent and with no regard for the social and ethnic culture of the team. This culture imbalance impacts on the qualities of meaningful work causing this too to become imbalanced and unequal.
In simple terms I would say :
Project success is a product of Teamwork & Communication
Teamwork & Communication is a product of Cultural Balance
Cultural Balance is a product of Meaningful Work
With Christmas fast approaching I thought I’d grab a moment to remind you of the busy year ahead at IASA so you can put placeholders in your diaries!
Next IASA Meeting: Applying Design Principles in Practice
Tuesday, January 12, 2010 from 6:00 PM - 9:00 PM (GMT)
Please note that there is a slight change of topic, but still the same great team will be presenting (see below for more information). I’m also delighted that the meeting will take place in a new venue so many thanks to Onalytica for letting us use their offices!
Click here to register
18:00 Welcome and IASA update
18:30 Design Principles in Practice
19:30 Drinks & Pizza
20:00 Design Principles in Practice cont'd
21:00 Close/Pub
Applying Design Principles in Practice
Nick Rozanski, Chris Cooper Bland, Eoin Woods
Design principles are generally applicable design rules that, when followed, result in desirable qualities in the design of software. In contrast to patterns, design principles don't provide concrete solutions to specific problems but rather are general guidelines that designers should be aware of when creating their designs. While design patterns are a practical embodiment of good design principles, we observe that many designers using patterns don't seem to understand the principles that make them work well. Examples of design principles are "maximise cohesion", "minimise coupling", "liskov substitutability principle", "don't repeat yourself/minimise duplication", ...
In this session, we will examine a specific set of design principles for distributed information systems that the presenters will provide. We'll examine the set from two directions, initially by applying them to specific, contrasting, design problems to see how they influence the design decisions made, how useful they are, and what is missing from the set. Then from the opposite direction, participants will explore how to relate the design principles back to higher level business goals and technical principles, so aligning the design with the system's wider environment. (This latter technique is enormously useful as a practical way of justifying hard-to-explain and possibly expensive design decisions to senior management.)
This process will allow us to analyse, understand and validate the set of proposed design principles, while also gaining experience in applying and justifying design principles to realistic scenarios.
Location:
Onalytica Ltd
29th floor centre point
103 new oxford street
WC1A 1DD London
United Kingdom
Click here to register
IASA Certification update
As you know the CITA certification program was launched earlier this year and we continue to work closely on various committees to look at bringing these to the UK in 2010. For more information and to register your interest then please visit the IASA certification website and let me know by reply to this email.
LinkedIn UK IASA Subgroup
Don’t forget the IASA and UK IASA LinkedIn groups. If you’re LinkedIn then please joinJ!
IASA LinkedIn Group
IASA LinkedIn UK Subgroup
Upcoming UK IASA Meetings
Please note the dates of the next scheduled meetings. I am considering subjects and think there is a need to cover cloud before too long! Any other suggestions then please let me know.
Tues 12th Jan 2010 Applying Design Principles in Practice
Tues 9th Mar 2010 TBC
Tues 11th May 2010 TBC
Tues 13th July 2010 TBC
Tues 14th Sept 2010 UK IASA AGM
Any news, thoughts or if you are interested in getting more involved then please let us know. And please have a thought on certification – and have your say!
So that’s about it for now and all there’s left to do is to wish you all a very Merry Christmas and a wonderful IASA New Year!!!
 | Jason Zander, GM for Visual Studio talks openly about Visual Studio 2010 and what's in store for developer architects with UML support etc. but what about wider out across the lifecycle? What about Enterprise Architecture and architecting the Lines? |
 | According to Roger Sessions in his recent white paper "The IT Complexity Crisis", the worldwide annual cost of IT failure is over $6 trillion a year and what’s worse is it is on the increase. The culprit, Roger believes, is complexity, which itself is directly related to function; increase function increases complexity. If we can manage complexity then we can increase IT success – “All we need is a process for making systems simple”. |
You know you’ve arrived when the SEI ask to post your video on their website – don’t you:)?
http://www.sei.cmu.edu/library/abstracts/videos/bassonarchitects.cfm
Only problem is I’ll never know how many people watched it as a result:(!
I’m a master of complexity and this week’s been no exception! Here’s a brief account of my week …
Monday & Tuesday
To start off I held the first proper meeting of my new focus group, the Microsoft Partner Architect Advisory Council (MPAAC), which is comprised of 18 senior architects from our GSI partners. In truth, this was our second actual gathering after the group’s launch and audience with Steve Ballmer back in October, but it was the first chance to get the group together to talk through real issues! We met for two days of discussion at the Weston Manor near Oxford, on the topic of “Microsoft in Tier 1” and to be honest I’m still revelling from the incredible amount of openness and creativity that this meeting generated given that we’d only just got started as a group! I think all of us saw the power and influence that this group could have if it is allowed to develop. However, there is still much to be done and much to prove we can achieve but first the output needs consolidating and reports need writing!
As part of this meeting it was my great delight to be able to invite the great Roger Sessions, CEO of Objectwatch and long-time architectural thought leader to join us at MPAAC. He travelled over from the US and spent the entire two days with the group to share his thoughts on project failures and the rise of complexity. He took part in the workshops and was a great motivation to all that took part!
Wednesday
Not having totally abused Roger’s good faith I managed to convince him to take part in a series of 1:1 meetings with a selection of customers and partners through out the day. Starting at 9am we ran through to 6pm talking to people about IT complexity and how you need to take a quantifiable and repeatable approach to simplification. Complex problems do not have to lead to complex solutions!
The key thing for me with the process and methodology that Roger talks to is that is is inclusive and empowering. It ‘removes’ the ego and democratises the decision making process leading to a shared ownership of and responsibility for the resulting architectural design.
So, with many more hours left in the day it was off to Soho for a Twitter dinner with other UK architect thought leaders @CyberSal, @richardveryard, @seebird20 and @taotwit – great curry, great conversation, great network boost – I love Twitter!
For more detail on Complexity I thoroughly recommend Roger’s white paper on The IT Complexity Crisis: Danger and Opportunity.
Thursday
Ok, time for a step change. As a Microsoft Environmental Ambassador (yes – great role hey;)!), I been following the progress of the Government’s Low Carbon Transition Plan and am a member on several Intellect groups such as the data centre and software as a service groups (although the paper the latter group is diabolical and I refused to put my name to it;)). Today it was the turn of the Smart Grids and Smart Metering Group’s Conference in which it was hoped that we’d hear the Government’s response to the recent consultation process but unfortunately this did not happen! That said, it’s not a response that is easy to write I suppose! 47 million smart meters to be rolled out to every home by 2020, a rate of maybe 35,000 a week in a market that is highly competitive, deregulated and incredibly complex market of generators, suppliers, distributors and add to this meter operators. Add to this the issues of duel fuel v separate electricity, gas and Water supplies, consumer choice, security of data, privacy of consumer (do you want your supplier to know when you put on the kettle or take a bath?), a lack of agreed standard protocols then you have a recipe for complexity the like of which was only last seen with the NHS Porgramme for IT originally estimated at £2.3 billion over 3 years by 2007 it costs were estimated at being in excess of £20 billion. the problem this down is that we’re not just playing with human health we’re playing with planetary health!
Here’s an interesting picture of a possible future which I found kind of fun … With Wind generation it is not beyond reality that energy could be free at certain points of a day and people incentivised to use energy:)! Well we can dream hey!
Top graph shows Energy production based on wind generation using UK wind speeds in 2008 (I think) against projected number of wind generators in 2030.
Bottom Graph shows market cost of this energy – when it blows the cost comes down:)!
Friday
So it’s back home on Friday and it’s catch up time; writing this blog; doing some internal training that’s due now; avoiding looking at expenses and editing down an interview I did with Roger back in October in NY which I have promised a million times to publish – fingers!
Ok that was this week … what am I up to next week … ah that’s right …
A session on the Implications of Cloud at the Business Cloud Summit on Wednesday and a session or two at the Architect Forum in the North with Black Marble on Thursday – a quiet week then … so maybe I can focus on some of the projects I’m meant to be delivering before Christmas:)!
 | Angela Yochem is an executive architect with a leading multinational organisation and an IASA fellow. Her public role and passion for architecture is incredible but it is her clear business focused approach that really sets her apart from the rest.
We constantly strive to align more closely with the Business to understand how we can move from servant to innovator. Angela has succeeded in going much further and is I would argue an integral part of the success of the business for which she works.
There is much we can learn from Angela and this interview only just touches the surface - thankfully Angela and people like her are open to continuing that conversation! |
Well, maybe they don’t actually ‘love’ the cloud but according to the research by MWD Advisors in partnership with the IASA it appears that they are cautiously optimistic which came as quite a surprise.
 | Neil, Research Director from MWD talked to me recently about their involvement with IASA and what they have started to uncover in terms of the value of architects in delivering “sustainable business value from IT investment”. He argues that it’s one of the big questions out there and architects are key in guiding the right levels of investment. The second half reveals some of the early findings of their research with IASA into the architects view on cloud computing which as I mentioned earlier were pleasantly surprising and encouraging given the need on business to continually reduce the costs of IT while still innovating in line with business needs. |
 | Talking Architects is a UK channel 9 series that I’ve just launched to reach out to prominent people within the Industry to discuss the issues that architects face.
If you think I should talk to you or to anyone you know especially in the UK then drop me a line! |
 | First up is Len Bass, co-author of Software Architecture in Practice and longstanding member of the Software Engineering Institute (SEI)whom I managed to talk to at the recent IASA ITARC conference in NY. Quality Attributes (Non-functional requirements) as first class citizens of a project? Too far fetched? Len, thinks he has an answer. |
been out a while but here’s a great interview* between Dave Gristwood and Dave Chappell on the value of Azure in comparison with other cloud platforms like AWS, Google AppEngine and Force.com well worth the time to watch!
* Ok, so when I say great video – I did the filming so am to blame for the “headless” shots and crass product placement!
Many thanks to everyone who took part in the Architect Forum on the 25th, and I mean everyone – I haven’t witnessed such a vocal audience in some time – really great mind share all round.
Here’s all the links to slides that were used and I hope to have videos edited before too long!
| Articulating the value of Cloud Computing
Neil Ward-Dutton, Research Director, MWD Advisors Before we can talk about value and selling the idea to the business, we have to be clear what we’re talking about! What is Cloud? From here we can start to understand the business case and scenarios and look at the entry points for enterprise investment. | |
Cloud Computing – What’s the Point?
Dave Coplin, Service Line Architect, Microsoft Ltd
Cloud Computing is being positioned as the future of the IT Industry, yet we collectively seem to be unsure on what it actually is and, more importantly, how to get from here to there. This session will attempt to reconnect us all with the longer term reasons on why the cloud is not just important but fundamental to the kind of transformation we are looking technology to provide the way we live, work and play.
| |
Architectural considerations for BPOS
Andrew Jones, Practice Director, CSC
The Microsoft Business Productivity Online Suite (BPOS) is a set of hosted messaging and collaboration solutions that currently include Microsoft Exchange Online, Microsoft SharePoint Online, Microsoft Office Live Meeting, and Microsoft Office Communications Online. This is the first wave of business focused finished (or SaaS) services from Microsoft extending the traditional on-premise model. On the surface the model appears simple but what are the considerations one must make in moving to a hosted model? What do you do about identity integration? How can you extend and customise the service? How do you provision the service and migrate? Is this a one way trip? How do you share services that are on-premise with those that are hosted? These are just some of the questions you need to ask as you peel off the label and start to look inside. In this session we will look at the key architectural considerations for moving to a BPOS solution, but also reflect on the fact that these can be converted to a general form and applied in any scenario where one is looking at a choice between software and service. | |
Windows Azure Overview
Dave Gristwood, Architect, Microsoft Ltd
There is a load of fuzz around Cloud, but in reality the actual implementations of cloud platforms are quite simple to describe and define. Azure is no different and this session attempts to provide a clear overview of Azure within 20 mins! | |
Patterns for Cloud Computing
Simon Guest, Senior Director of Technical Strategy in the Developer and Platform Evangelism (DPE) group, Microsoft Corp
Everything that you read these days seems to suggest that you should be moving to the cloud. But where do you start? Which applications and services should you be moving? How do you build the bridge between on-premises and the cloud? And more importantly, what should you be looking out for along the way? Based on real-world scenarios, this session explores a set of pattern for applications that best take advantage of the cloud, together with working examples on the Windows Azure platform. This session provides the tools and knowledge to determine whether cloud computing is right for you, and where to start. | |
