Wednesday, January 27, 2010

Architecture Anti-Patterns: Pattern #1 - Architecture by e-mail

Anti-patterns seem to be going a bit out of vogue these days. I like them as a way of capturing our occasional follies. I will periodically record some of them here starting with Architecture by e-mail.

AntiPattern Name: Architecture by e-mail

General Form:
Large numbers of e-mails with long chains attached are sent between architects and designers which encompass important architectural decisions.  

Symptoms and Consequences:
  • People spend a lot of time on e-mail rather than focussing on work products or deliverables.
  • Important information communicated via e-mail is lost or ends up being stored on individuals workstations.

Refactored Solution:
  • Capture important decisions in the right place (e.g. an Architectural Decisions work product and use this as the vehicle for discussing options.
  • Use meetings or conference calls to discuss options and drive out decisions.

Tuesday, January 26, 2010

Architect Roles

The IT industry tends to bandy around a number of different architect roles. Working with different clients, as I do, I find there is often confusion about what all these roles do. I find the following diagram helps to explain the different roles that IT architects take. Of course the important point to emphasise is that these are roles not job titles. In other words, one person may take on multiple roles on any given project so this is not meant to be a a way of generating architecture jobs but is merely a way of showing the different skill areas or disciplines that need to be applied when building a solution that is comprised of multiple layers.

Tuesday, January 19, 2010

Tim Brown on Design Thinking

If you don't watch any other TED podcasts watch this one by Tim Brown. IBM sponsored TED at Oxford last year (no invite for me unfortunately) and Tim Brown (CEO of IDEO) presented on Design Thinking and had these ideas which I think apply equally to architectural thinking (is it different anyway).
  • Big problems need big solutions. Back in the 19th century Isambard Kingdom Brunel imagined an integrated transport system (he thought big). His vision was that of a passenger boarding a train in London and leaving a ship in New York. Big problems (global warming, health care, international security) need big thoughts to provide solutions. Focussing on the small may provide incremental change but will not provide solutions to some of the big, hairy problems we are faced with today. If we could focus less on the object (the individual system in IT terms) and more on design thinking (systems of systems) we might have more of an impact and be able to solve more of the really difficult problems there are out there.
  • Design thinking begins with integration thinking. Design thinking needs to balance a number of fundamental “forces”: what people want (desirability), what technology can provide (feasibility) and what can actually be built given the constraints of cost, resource and time (viability). 
  • Design is (or should be) human centred. Although it needs to be both feasible and viable if it is also to be desirable then that needs to start with what people need. Here the needs we are considering are not what we want from the next version of iPod or Porsche but a safer, cleaner, healthier world. Understanding the needs of the multiple stakeholders that there are out there when building big systems is crucial of the systems are to be not only desirable but also useful. 
  • Learning by making. Don't just think what to build but also build in order to think. In todays model-driven world where we architects can often go off into a huddle for months on end we sometimes forget that the important thing is not a very fine model or specification but the thing itself. Prototyping is as important today as it's ever been but we sometimes forget that getting our hands dirty by and building small-scale throwaway parts of systems is an important way of learning and understanding those systems. As Fred Brookes said, you might as well plan to throw one away because you will anyway.
  • From consumption to participation. Design of participatory systems where everyone is involved will lead to new and innovative solutions which may not have been envisaged initially. This is the idea that the whole is greater than the sum of the parts and in IT terms is best articulated in Web 2.0 and the whole social networking phenomenon.
  • Design is too important to be left to designers. Often the important innovations come not from the people charged with designing the system but from the people who are using  the system. Don't forget that the most important stakeholders are the everyday users or the current system.
  • In times of change we need new alternatives and new ideas. We are living in times of great change and our existing systems are no longer fit for purpose. Design thinking needs to explore new and unthought of ideas without being constrained by current systems and ideas. Design thinkers need to be multi-talented, left and right-brain thinkers. Hint: this will also increase dramatically your chances of staying employed in the coming years. Good design thinkers know that the key to a good and better design is asking the right question or at least framing the question in a way that will not constrain the solution. So, rather than asking “how do I build a better benefits system” ask “how do I build a benefits system that will result in more of the benefits reaching the people who need them most and less in paying people to run the system”. Of course this is hard because answers to such questions can sometimes have difficult or unpalatable side-effects such as people losing their jobs. The first step of design thinking is to ask the right question.
There are lots of ideas here and many of them resonate with the practice we in IBM call Architectural Thinking. I will return to some of these ideas in future blogs.

Thursday, January 7, 2010

Attributes of an IT Architect

I've recently been reviewing some course material for a further education institute here in the UK to see how well suited the material was for preparing students to enter the IT industry. This made me think about what skills we as IT architects really need to have. The following points describe (some) of the realities of working in a business/IT services company as we enter the second decade of the 21st century. They are intended to act as a reality check to enable new entrants into this profession to assess their skills. In my experience these are all skills that an effective IT architect needs to master or at least be aware of.
  1. Understand Business Drivers. Cost reduction is the number one driver for businesses. IT for the sake of IT is no longer an option for a business' IT department (was it ever, really). IT must be seen as being responsive to the needs of the business. If IT is not seen as removing cost from the business then no business case will ever (or should ever) be signed off by the board. As a consequence of this the market for service providers is fiercely competitive and when responding to Invitations to Tender (ITT) service providers must be acutely aware of this. Bids are often won purely on price.
  2. Work With Offshore Developers. As a further consequence of 1) as much work as possible is put out to off-shore, low-cost economies. This applies to most aspects of programming, package integration, web development and test. Whilst knowledge of object-oriented techniques, Java programming etc is useful it is unlikely to be a major part of the day to day work of an IT professional in a services company. Instead we must be aware of the cultural and social differences and work effectively with these folk.
  3. Understand Complex Systems Integration. Today the really wicked problems are in the area of complex systems integration (CSI). With mergers and acquisitions (M&A) in large multi-nationals occurring regularly as well as all government departments wanting to reduce costs by merging departments or systems this is a trend that is only going to increase. As a consequence understanding how to interface between systems (at a technical level) is crucial. My colleague Jeremy Caine blogs on this topic. In particular Jeremy has a nice entry here which links this and my point 5) below.
  4. Be Aware of Organisational Aspects. A further consequence of 3) is that it is not only technical integration which is needed but also organisational integration. Dealing with the points-of-view, biases, entrenched views etc of people in organisations is often more difficult than dealing with the technical aspects.
  5. Apply Processes Pragmatically. The pressure to deliver projects quickly often means that software delivery lifecycle (SDLC) processes are by-passed, overlooked or just not followed at all. Understanding how to apply processes in a pragmatic and efficient way is key to a successful system delivery project.
  6. Manage Stakeholders Effectively. Stakeholder management is crucial to effective and successful systems development. Understanding who the stakeholders are, their motivations and interests as well as how they interact with each other is a key skill for an IT services professional.
  7. Manage Non-Functional Requirements Effectively. Whilst the industry is fairly good at gathering functional requirements it is still very bad at defining non-functional requirements (i.e. the systems qualities and constraints under which it must be built and operated). IT professionals need to understand how to gather and analyse these.
  8. Understand Package Integration. The majority of systems being built today are a combination of packages, integration with existing systems and (relatively small) bespoke development. Understanding packages (e.g. from companies like SAP, Oracle) and products (such as IBM's WebSphere Message broker) is therefore a key skill.
  9. Apply Systems Engineering Techniques. Systems are not just about software! Understanding the people, process and deployment aspects of systems is equally, if not more important.
  10. Understand Application and Infrastructure Management Issues. Systems, once built, have to be run and maintained. Understanding how to work with infrastructure providers and application maintenance providers early on in a project is therefore crucial.
  11. Be Aware of Enterprise Level Computing. Understanding the business at an enterprise-level (i.e. business and IT enterprise architecture) rather than at just the parochial system or project level is key to delivering successful IT projects. An IT system rarely works in isolation but instead needs to operate in a complex eco-systems consisting of multiple interacting systems if the propagation of more, siloed business systems is to be avoided.
  12. Don't Forget the Human Computer Interface. In a similar way that the process is often overlooked, the effective design of the human-computer interface (HCI) is also regularly overlooked. In a business system, where interfaces are being used all day long and a few effectively designed shortcuts can literally save hundreds of hours work.
I will return to some of these themes in future blogs.

Wednesday, January 6, 2010

Does Architecture Matter Any More?

I’ve been reading up on the whole cloud/mashups/social computing thing and the above question occurred to me. Within the context of what are essentially several new architectural styles what is the role of the architect in all of this and what exactly is the architecture he or she is trying to create? In attempting to answer this question my mind diverted to an IT architecture course that I have been lucky enough to teach on a number of occasions both inside and outside IBM. The course is called Architectural Thinking. I imagine (hope) that some people reading this will have attended that class and it occurred to me just how clever the people that created the first version of that class back in 1999 were. The key word of course is thinking. It’s not a class about a particular style of architecture, about a particular architectural process and is certainly (thankfully) not about any particular technology. The key part of that class is about how to think about problems and create architectures, often using an existing style or pattern, to come up with solutions to a client’s business problem. The main axiom being that the architecture should drive the technology and not the other way round. In other words it’s about the fundamentals that never go out of style or, to paraphrase Grady Booch:

Architectural styles come and go but the enduring fundamentals (crisp abstractions; clear separation of concerns; balanced distribution of responsibilities; simplicity) endure and never go out of style.

This course is available outside of IBM for clients so if anyone is interested in running the class get in touch with me on here.

Tuesday, January 5, 2010

Architecture for a New Decade

Predicting the future, even 12 months ahead, is a notoriously tricky past-time. Arthur C. Clarke the English scientist and science fiction writer who sadly died in March 2008 said:

If we have learned one thing from the history of invention and discovery, it is that, in the long run - and often in the short one - the most daring prophecies seem laughably conservative.

As we move into a new year and a new decade the world, in my memory at least, has never seemed a more uncertain place. As the doom and gloom merchants predict an even more troubled economy and the ongoing threats from global warming, increasing pressure on dwindling natural resources and yet more wars do not make for a happy start to 2010.

Whilst solving these truly wicked problems is slightly beyond me I am left to wonder what this new year brings for us architects. According to Gartner the top 10 strategic technologies for 2010 include a number of things which we as an architect community need to be getting our heads around . Of the list of ten, there are three technologies in particular that interest me:
  • Cloud Computing
  • Advanced Analytics
  • Social Social Computing
Whilst it is easy to get consumed by the technology that these new architectural “styles” bring to the table I think the key things we as architects need to do is:
  1. Gain sufficient understanding of these architectural styles to be able to articulate their benefits (and of course their risks) to clients.
  2. Understand what the real difference between these technologies and the one that went before it are so we can build solutions that take advantage of these differences rather than more of the “same-old-architecture” in a slightly different guise.
  3. Figure out how we sell these benefits to the really important stakeholders (the RIS’s).
I reckon that in 2010 being able to identify the RIS’s and convincing them of the business benefits of going with solutions based on technology X is going to be the absolute number one priority. Most businesses in 2010 are going to be struggling to survive and not thinking about IT spends. However survival needs businesses to be both agile and also have the ability to swallow less fortunate companies as efficiently and quickly as possible. Thankfully I think the really good architects that can do this and span the business-IT gap will still be around this time next year. I’m not sure about the rest though?