Architecture Refuseniks

Peter Cripps architecture ,

re-fuse-nik (noun) a person who refuses to cooperate with a system or comply with a law because of a moral conviction

Some IT architecture refusenik types who may or may not have moral convictions about this sort of thing:

  1. It’s all in the code – Just wants to get on with cranking out what really matters (to them) the code. Thinks that anything to do with architecture is poncey nonsense and that all architects need to “get real” and realise that code is king.
  2. It’s all in the process – Can create the worlds most complex process that will deliver, er well nothing actually because no one will ever take any notice of it and just get on with the real work anyway.
  3. It’s all in the clouds – Will pontificate endlessly on things like ‘governance’, ‘process’, ‘reviews’ but will never actually deliver anything.
  4. It’s all in the model – Opposite of the coder. Thinks the system is completely describable by models and says their work is done, and the system is ‘complete’ once 35 (or more) UML models have been created.
  5. It’s all in the plan – As long as we have a plan that is at least 8 levels deep and has every minute of every day accounted for it’ll all just work at the end of it.

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.

Tim Brown on Design Thinking

Peter Cripps Technology

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.

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.