architecture

IT Architecture and Wicked Problems

Peter Cripps architecture ,

A wicked problem is one that, for each attempt to create a solution, changes the understanding of the problem. A wicked problem exhibits one or more of these characteristics:

  1. The problem is not understood until after the formulation of a solution. Despite your best efforts you don’t actually know what the problem really is and developing solutions only shows up more problems.
  2. Wicked problems have no ‘stopping rule. That is to say if there is no clear statement of the problem, there can be no clear solution so you never actually know when you are finished. For wicked problems ‘finished’ usually means you have run out of time, money, patience or all three!
  3. Solutions to wicked problems are not right or wrong. Wicked problems tend to have solutions which are ‘better’, or maybe ‘worse’ or just ‘good enough’. Further, as most wicked problems tend to have lots of stakeholders involved there is not usually any mutual agreement about which of these the solution actually is.
  4. Every wicked problem is essentially novel and unique. Because there are usually so many factors involved in a wicked problem no two problems are ever the same and each solution needs a unique approach.
  5. Every solution to a wicked problem is a ‘one shot operation’. You can only learn about the problem by building a potential solution but each solution is expensive and has consequences.
  6. Wicked problems have no single solution. There may be lots of solutions to a wicked problem any one of which may be right (or wrong). Its often down to personal (or collective) judgment as to which one to follow or adopt.

By reading the list of properties that wicked problems exhibit you can easily see that many (or even most) large and complex software development projects fall into the category of wicked problems. Especially those which involve many stakeholders, multiple systems and difficult social, political, and environment challenges (e.g. such as building a nations social security or health system) or re-engineering an enterprises core systems whilst still trying to run the business.

I think that the really interesting and challenging roles out there for us IT architects are in tackling some of the wicked problems that many large and complex systems engineering projects contain. In my experience it is very often not just the technological aspects of the problem that needs to be addressed but also the social, political and economic aspects as well. I think the real challenges and also key roles that IT architects will take as we move into the next decade are in bringing new and creative approaches to solving these wicked problems. I’m currently preparing a lecture to be given at a UK university next month around this theme.

Architecture Anti-Patterns: Pattern #4 – Too Many Chiefs

Peter Cripps architecture ,

Anti-Pattern Name: Too Many Chiefs
General Form:
A large project or program is top-heavy with architects. Lots of high-level pictures and documents get produced but no real specifications are created.
Symptoms and Consequences:

  • The project has been running for several months and there is no clear plan.
  • Lots of high-level documents not following any obvious templates or serving any useful purpose (e.g. “Functional Specification”) are created.
  • No detailed specifications are in evidence (e.g. Component Models, Operational Models).
  • Overuse of MS Office products rather than “real” architecture tools.

Refactored Solution:

  • Ensure all roles are well defined and have clear deliverables.
  • Ensure all architects understand the process they are following.
  • Ensure there is a clear plan with roles and deliverables assigned.
  • Instigate use of professional tooling

See Pattern #3

Design Really Does Matter

Peter Cripps architecture , ,

I’ve just received a new work laptop and what a monstrosity it is! There was a time when ThinkPads were actually quite sexy as far as laptops go but this model (a T400 if you’re interested) is a complete abomination of a thing. It’s not only square and clunky feeling but for some mysterious reason the designers have made the battery stick out of the back like some large cancerous growth. Why, if Apple can design a laptop with a supposed 6 hour battery life where the battery is hidden completely inside the case do Lenovo designers have to create something that has the battery hanging out the back and appear to offer no more life?

What’s all this got do do with the zen of architecture you might ask? I’ve been reading the latest book by Garr Reynolds, Presentationzen Design where Garr suggests we should take inspiration for good design from the products we see around us all day. The ThinkPad would seem to be a good design antipattern to me. Of course, as Hugh MacLeod says “there’s no correlation between creativity and equipment ownership” and “a fancy tool just gives a second-rater one more pillar to hide behind.” That said, I feel sure that using a tool that is both good to look and is well designed makes for an all round better experience that must aid in the flow of the creative juices. If you don’t have the ideas in the first place then the best tool in the world won’t help you create them but if you do have something to say what would you rather write with, the free pen from the hotel room or the Mont Blanc you got for Christmas?

Architecture Anti-Patterns: Pattern #3 – Throwing Out the Baby with the Bath Water

Peter Cripps architecture

Anti-Pattern Name: Throwing Out the Baby with the Bath Water
General Form:
A new idea, technology or process comes along and everyone jumps on the bandwagon forgetting the fundamental principles developed previously.
Symptoms and Consequences:

  • Lots of external and internal “marketware” describing the benefits of the new approach but often with very little substance behind them.
  • People being encouraged to go on education, join working groups etc where the new approach is described.
  • Skills in “legacy” technology become difficult to find as everyone is now trained in the new approach

Refactored Solution:

  • Ensure fundamentals are captured as principles and approaches in existing methods and processes.
  • Reinforce through training and good governance.
  • Take care when/how to adopt the new approach.

See Pattern #2

Architecture Anti-Patterns: Pattern #2 – Groundhog Day

Peter Cripps architecture , ,

Anti-Pattern Name: Groundhog Day
General Form:
Important architectural decisions that were once made get lost, forgotten or are not communicated effectively.
Symptoms and Consequences:

  • People forget or don’t know a decision was made.
  • The same decision is made more than once, possibly differently.
  • New people joining the project don’t understand why a decision was made.

Refactored Solution:

  • Capture important decisions in the “Architectural Decisions” work product.
  • Ensure a process is in place for making and ratifying decisions (maybe a Design Authority responsibility).
  • Ensure decisions get known about by all the right people.

See Pattern #1

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

Peter Cripps architecture

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.

Anti-Pattern 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.

Architect Roles

Peter Cripps architecture ,

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.

Attributes of an IT Architect

Peter Cripps architecture , ,

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.

Does Architecture Matter Any More?

Peter Cripps architecture , , ,

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.

Architecture for a New Decade

Peter Cripps architecture , , , , ,

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?