architecture

We Need More Women (IT) Architectural Thinkers (Duh)!

Peter Cripps architecture , , ,

Yes I know, a statement of the blindingly obvious. People of have been bleating on about this for years but nothing much seems to change. My recent and current experiences of teaching IT architecture for a number of different clients rarely has more than 10% of the classes being made up of women (and its usually 0%!). Even more depressingly, from what I’ve seen of university IT courses, there seems to be a similarly small number of female students entering into careers in IT. So why does it matter that 50% of the worlds population only have such a poor showing in this profession?

In his book Change by Design Tim Brown, CEO and president of IDEO relates the following apocryphal story. Whilst working on a kid’s product for Nike IDEO gathered a group of kids at their Palo Alto design studio to brainstorm ideas. The boys and girls (who were eight to ten year olds) were split into separate groups in different rooms, given some instructions and left to get on with it for an hour. When the results were analysed it was found that the girls had come up with more than two hundred ideas whereas the boys had struggled to come up with fifty. The reason for this? The boys were eager to get their ideas out there and were barely conscious of of the ideas of their fellow brainstormers. The girls on the other hand “conducted a spirited but nonetheless serial conversation in which each idea related to the one that had come before and became a springboard to the one that came next”. According to Tim one of the key rules of brainstorming is to “build on the ideas of others” and it would seem girls have an innate ability to do this whereas boys, possibly due to their more competitive tendencies, want to force the ideas to be the ones that “win”.

Although this story relates to a group of eight to ten year olds my own anecdotal evidence indicates it is equally applicable to all age groups. When observing how team members interact on case studies that we run as part of our architecture classes there is inevitably better and more informed discussion and end results when the teams are mixed (even when females are in the minority) than when they are made up of all males.

My hope is that we are entering a new age of enlightenment when it comes to how we put together project teams that are made up of true versatilists rather than traditional teams of “hard-core” IT techie types. Versatilists by definition have good skills across a range of disciplines whether it be in the arts, humanities or sciences. It is, I believe, only in bringing together both this range of disciplines together with mixed genders that we can hope to address some of life’s harder problems. Problems that not only require new ideas but solutions that build on the ideas of others rather than re-inventing everything from scratch in the usual brute force, testosterone charged way we typically seem to approach problem solving in IT.

Are Frameworks Too Constraining and is Chaos the Natural State?

Peter Cripps architecture , , ,

ZapThink have recently published a number of good articles on complex systems, the death of Enterprise Architecture and the dangers of ‘checklist architecture’. These have resonated nicely with some of my thoughts on the state of (IT) architecture in general and whether we are constraining ourselves unnaturally with the tools, processes and thinking models we have created. Here are the problems that I see we have with our current approach:

  1. Systems are getting ever more complex but we are still relying on the same-old-processes to deal with that.
  2. We have processes which are too large, overblown and themselves too complex which lead to people being driven by the process rather than the business goals for the system(s) under development.
  3. We are creating siloed professionals who are aligning themselves to particular disciplines; for example: Enterprise Architect, Solution Architect, Integration Architect the list is almost endless! This results in sharing of responsibilities but no one person or group retaining the overall vision.
  4. The majority of enterprises faced with addressing these challenges themselves have such large and complex bureaucracies in place that the people working in them inevitably end up becoming ‘inward facing’ and concentrating on their own needs rather than solving the complex business problems. There is of course an interesting dichotomy here which is: do we develop systems that just reinforce the status-quo of the systems we live by?

What we need is a new approach which both encompasses the need to address the complexity of systems we must build but at the same time allows for the change and chaos which is almost the natural state of human affairs and allows new and interesting properties and behaviours to emerge. As I’ve said elsewhere what we need is a new breed of versatilists who, just like the Vitruvian man of Leonardo da Vinci, can bring to bear a whole range of skills and competencies to help address the challenges we face in building todays complex systems. I think what we need is an update of the agile manifesto. This won’t just address the relatively narrow confines of the software delivery processes but will be far more extensive. Here is my first stab at such a manifesto.

  1. Systems of systems rather than single systems.
  2. Business processes that provide automated flexibility whilst at the same time recognising there is a human and more collaborative element to most processes where sometimes new and unexpected behaviours can emerge.
  3. Adaptable and configurable software delivery processes that recognise business requirements are dynamic, unclear, and difficult to communicate rather than a single, monolithic ‘one size fits all’ approach that assumes requirements are stable, well understood, and properly communicated.
  4. People that objectively view experiences and reflect on what they have learnt, look further than their current roles, explore other possibilities and pursue lifelong learning rather than those that focus on the narrow confines of the current project or how to better themselves (and their employer).
  5. Enterprises (whether they be consulting companies, product developers or end users or IT) that recognise the intrinsic value of their people and allow them to grow and develop rather than driving them to meet artificial goals and targets that feed their own rather than their clients/customers needs.

When Does an Architecture Become a Reference Architecture?

Peter Cripps architecture , ,

A reference architecture (RA) is a particular kind of reusable asset that is basically a “ready-rolled” architecture that has been used and proven in a number of other situations and can be applied (wholly or partly) to to solving different problems (though within a particular context). The question is, when does the  architecture of a system become one that can be reused elsewhere and therefore become a reference architecture? I have a colleague, Bruce Anderson, who was instrumental in the early pattern movement who once said to me that something can only be called a pattern if there are at least three known instances of it. One of the things that made the famous Design Patterns book so powerful and continues to make it so enduring is that it was based on rigorous research by the authors who trawled through several systems designs to look for common themes and harvest them into the catalogue of patterns that make up the book. Whilst a reference architecture could be considered a kind of pattern it has some differences that make it harder to find multiple instances that are already ‘out there’. Namely:

  1. A reference architecture is, by definition, a large-grained asset typically made of  many subsystems which in turn are made up of interdependent components. There are many ways of assembling these components together, any one of which will usually do the job. It is unlikely therefore that exactly the same assembly of subsystems and components will exist in more than one architecture. Consider the architecture of an online retail store for example. There will be subsystems for allowing new customers to register and change there contact details, managing the ordering process and for managing the database of products that are for sale. However the internal components that make up these subsystems could be wired together in many different ways. Who is to say which is best?
  2. Architectures at the system level are typically documented in a multitude of different ways. Some may use rigorous modelling languages such as SysML captured in a modelling tool whilst others use more informal documentation consisting of pictures and words captured using a word processor. This makes it difficult to compare like with like when trying to find “best of breed” which is, after all, what we are trying to do when harvesting architectural assets.
  3. Large-grained assets consisting of complete architectures are likely to contain a considerable amount of intellectual property that give companies competitive advantage so they are unlikely to offer them up as potentials for becoming an industry reference. Some subsystems my be covered by patents (amazon’s one-click ordering for example) so are at least accessible but many will not be generally available for anyone to view.

These three factors (and there are probably more, feel free to comment) make it difficult to find similar architectures, compare them to see which is best and to harvest them as a reference for others to use which is the whole intent of the patterns movement. What to do?

  1. Reference architectures can be built. With an enterprise, a bank for example, it should be possible to build a reference architecture bottom-up. By deploying architects with the right industry and technology skills components can be selected and assembled in an optimum way that makes most sense for that organisation. This can then be a reference for other parts of the organisation to use. For companies that provide consultancy across multiple clients this can be a very powerful way to achieve reuse across projects however it does require a significant up-front investment as well as ongoing maintenance to keep the architecture current.
  2. Reference architectures should be described using a standard approach. It helps to document architectures using a standard set of work products. In the book The Process of Software Architecting we describe a set of work products that can be used for documenting a systems architecture (Architecture Overview, Functional Model, Deployment Model, Architecture Decisions etc). The point about using a standard set of work products to describe a reference architecture is that these can then form the basis of the documentation of the system that is to be built based on the reference system.
  3. Reference architectures are made to be changed, not used as-is. Once a reference has been defined it will almost certainly be changed to a lesser or greater extent depending on its “fit-gap” to the requirements of the new system. It’s usually worthwhile to do a formal fit-gap analysis to determine this and to use the output as part of the documentation of the new system.
  4. For reference architectures context is critical. This really follows from the previous item. Knowing the context (functional and non-functional requirements) is critical to the applicability of a reference architecture being reused. There is a danger it will be forced to fit when it makes no sense to do so. For example the new system has particularly stringent performance requirements that mean the way components are wired together in the reference architecture cannot be applied to the new system.

A reference architecture is associated with a particular domain of interest (retail banking, online commerce etc) and typically includes many different architectural patterns, applied in different areas of its structure. Since a reference architecture is an architecture, it is no surprise to find that the best  reference architectures are described in exactly the same manner as any other architecture using the same work products.

How Not to Create Artitecture

Peter Cripps architecture ,

Following on from my previous post what should we do if we just want to create a SOA (same old architecture) rather than a TOA (totally outrageous artitecture)? Here are five things you should do if you want average rather than exceptional architectures (anti-patterns for ineffective architecture if you like):

  1. Focus on what your employer wants you to do (your job) rather than what your client wants you to do (your work). How much time is the project team spending excessively networking obsessing over recording data that is not project related and of dubious use anyway or attending endless meetings which don’t have a clear agenda or any useful outcome.
  2. Start committees instead of taking action. Like most things in life the best architectures don’t come from committees but come from the focussed efforts of a small team of architects. Sometime that small team can be just one person (consider Tim Berners-Lee’s world-wide web or Ray Ozzie’s Lotus Notes). Committees (we call them Design Authorities in technical circles) may have their place when multiple stakeholders need to be bought together but don’t confuse governance (i.e. controlling the steady-state) with design (i.e. initiating a change of state). Unfortunately there is safety in committees where there is no single person responsible for decisions and no one individual can be blamed when something goes wrong.
  3. Create a culture of blame and negative criticism where everyone has to watch their back. Many people on projects interact with others as though they are better than their peers or want to teach them a lesson. Others assign motivations and plots where there are none. Still others criticise anyone who is doing something differently from the norm. Mistakes happen and are usually the result of a series of unfortunate events rather than deliberate negligence or dishonesty. Learn from mistake and move on.
  4. Stop people from learning. Not allowing or fostering a learning culture is probably one of the gravest crimes that can be committed in the conceptual age. Learning does not just have to come from attending classroom based courses (or the dreaded “online training”) but should come from everything we do. Treat every type of interaction with a person (talking to them, reading their blog or whatever) as an opportunity to learn something new.
  5. Produce overly complex and outlandish work products. The problem with many delivery processes is that they can demand large numbers of work products that, when taken literally, will pull the team down into a never ending spiral of “document production” where every deliverable has to be signed off before progress can be made. Delivery processes and the work products they produce should be highly customised to the projects needs not the needs of stakeholders that demand huge volumes of written material which no one needs let alone reads.

Not having any/all of these is not a cast-iron guarantee you will succeed in building great systems based on innovative architectures but having them will certainly ensure you have architectures not artitectures.

How to Create Artitecture

Peter Cripps architecture , , ,

Forgive me for pushing yesterdays entry a bit further but I really like the idea of creating architectures that come from more of a right-brained way of thinking. So how should artitects go about creating an artitecture?

  1. Thrash early. Thrashing is a term used to describe the creative brainstorming process that happens during a project. Seth Godin in his book “Linchpin – Are You Indispensable?” says that amateurs thrash late whereas as professional thrash early. Late thrashing introduces bugs which are better to identify early rather than later.
  2. Make mistakes and learn from them. Like Fred Brooks said: “plan to throw one away; you will anyhow”. Use prototypes to understand how new and technically challenging components work but treat these as throwaways not release 1.0!
  3. Deliver (ship) something. According to Steve Jobs “real artists ship”. Delivering something (anything) on time and within budget is one of the great challenges of software development. Time or money (or both) usually run out before anything is delivered. Here’s a different way of looking at it though. Why not see the time/money constraint as a positive rather than a negative aspect of a project? So, if you have to produce something on time and within budget it’s quite simple really. Just work until the time/money run out then deliver something.
  4. Read the rule-book, but then change it. For software development projects the “rule book” is usually the process that is meant to be followed. However it’s important to recognise that there is no “one size fits all” when it comes to SDLC (software delivery lifecycles). SDLCs are good but don’t follow them too slavishly. Be ready and prepared to customise them to your needs. A good SDLC will have this flexibility.
  5. Seek forgiveness not permission. I got this from an ex-colleague. In many companies today you are overwhelmed by (often) petty rules of engagement. If you always follow the rules that are supposedly “needed” to get a piece of work done then you won’t deliver. You’ll have done your job (followed the rules) but won’t have done the work that your client wants. Better is to not follow every rule and ask permission for doing something but to just do it and ask for forgiveness when the rules get broken (unless those rules are there to keep you out of prison of course).

Okay here’s the real irony in the above. If you read and believe my point number two from yesterday (artitects don’t follow the process in the manual, instead they write the manual) you won’t be following any of the above; instead you’ll be creating your own way of doing artitecture.

Are Architects Cogs or Linchpins?

Peter Cripps architecture, creativity

I’m reading the book Linchpin – Are you indispensable? by Seth Godin. It raises in my mind a number of troubling thoughts about architects and whether we can be viewed as being cogs or linchpins according to Seth’s world view. According to Seth a cog is someone who:

  1. Relies on left (lizard) brained skills
  2. Keeps their head down
  3. Follows instructions (or a process)
  4. Creates widgets
  5. Works hard but just does what is needed
  6. Shows up on time
  7. Gets jobs by providing a CV (AKA resume)
  8. Is easily replaced (by another cog)

whereas as linchpin is someone who:

  1. Relies on right (creative) brained skills
  2. Raises their head above the parapet
  3. Makes judgment calls and leads others
  4. Creates art
  5. Focuses on connecting people and ideas
  6. Work to no fixed schedule or agenda
  7. Gets jobs by pointing prospective employers at their web site, blog, latest work of art or project
  8. Is indispensable

As with any job IT architecture is x% slog and routine and y% creativity, inspiration and creating great ideas or opportunities. By working on the linchpin attributes rather than the cog attribute you can hopefully increase y at the expense of x. I think this resonates well with these skills and my manifesto here.

Architecture Anti-Patterns: Pattern #6 – Architecture Thinking Not Doing

Peter Cripps architecture ,

Anti-Pattern Name: Architecture Thinking Not Doing
General Form:
An organisation or enterprise embarks on an initiative to retrain their designers and developers to be ‘architects’. They set up education classes, assign new roles to their people with the word ‘architect’ in their job title and may even pay them some more money to match their ‘elevated’ status. However after a period of time (could be 6 months, could be longer) the initiative dies, developers just keep developing, designers just keep designing and no true system architectures materialise.
Symptoms and Consequences:

  • People return from training but make no changes to their behaviour. They revert to whatever it was they were doing previously.
  • The person(s) responsible for the initiative move on and as it was “their baby” the initiative dies.
  • Management think that training is sufficient and that once students have been trained they will “know what to do differently”.
  • People want to put into practice what they have learnt but have no idea where to go for help or guidance.

Refactored Solution:

  • Architecture thinking has to be turned into architecture doing. Follow up training with projects which make immediate use of new skills.
  • Identify early on who the real leaders are and get them to mentor others.
  • Obtain a critical mass of core people who will continue to develop their skills and be advocates of the new approach even once the initial hype has died down.
  • Ensure the initiative to train architects has support from the highest (i.e. CxO) level of the organisation.
  • Get buy-in from the business as well as IT. Convince the business of the need for architecture by showing them time to market and quality will improve and their will be less maintenance costs.
  • If the organisation is immature but keen to learn ‘buy-in’ experience either by hiring experienced people or working with good technical consultancies who have a proven track record (or some mix of both).
  • Follow up training with good quality, written down guidance (including guidelines, examples and templates) which is readily available and easily found (preferably in the companies website).
  • As part of the training get a written-down commitment from each student that describes one thing they will do differently as a result of attending this training. Follow this up and see if they did it. If not find out why not.

See Pattern #5

Architecture Anti-Patterns: Pattern #5 – Death by (Technical) Presentations

Peter Cripps architecture ,

Anti-Pattern Name: Death by (Technical) Presentations
General Form:
A presentation on a technical topic contains many, many slides of tightly packed text with overly complex diagrams that are difficult to read close up let alone from any distance away.
Symptoms and Consequences:

  • You’re invited along to a presentation where the architecture will be “presented”.
  • The presentation consists of 167 slides in mainly 12pt font with closely packed words on each page.
  • The presenter often says things like “I’m sorry you can’t see this from the back” or ” I’m going to skip over this slide as it’s not really relevant”.

Refactored Solution:

  • Read this book and visit Garr Reynolds blog for ideas and inspiration
  • Architectures should be created as models in a legitimate modelling tool. It’s okay to cut and paste pictures into a presentation tool such as PowerPoint as long as they can easily be viewed and are meaningful.
  • Make sure presentations are consistent in their use of layout, colour and fonts.
  • Don’t attempt to put all the information in a presentation. Refactor to contain the key points only.
  • Put the detailed information in handouts which are given out after the presentation.

See Pattern #4

Why Do Complex Systems Projects (Still) Fail?

Peter Cripps architecture , ,

Depending upon which academic study you read, the failure rate of complex IT projects is reported as being between 50% and 80%! I thought I’d test this against my own experiences and took a look back over my career at the number of complex systems I have worked on and how many could be counted as being successful. Clearly the first thing you need to do here is to define “complex” and also “success” so I’m defining complex as being a system with:

  • Multiple stakeholders involved.
  • Multiple systems interfaces.
  • Challenging or high risk non-functional requirements (including delivery schedule and budget).

and “success” as being:

  • Delivered on time and within budget.
  • Met the stakeholders requirements.
  • Went into production and ran for at least 12 months.

By my count I have worked on 18 projects which meet the first set of criteria and of those I reckon 8 meet the second set of criteria so can be thought of as “successful”. So that’s a slightly under 50% success rate! Not brilliant but within the industry average (which is of course nothing to brag about).
As you might expect there is a wealth of information out there on the reasons why IT projects fail. Top amongst these are:

  • Lack of agreed measures of success.
  • Lack of clear senior management ownership.
  • Lack of effective stakeholder management.
  • Lack of project/risk management skills.
  • Evaluation of proposals driven by price rather  business benefits.
  • Projects not broken into manageable steps.

These typical failings were highlighted in a joint British Computer Society/Royal Academy of Engineering report from 2004 called The Challenges of Complex IT Projects. That was six years ago and I wonder what has changed since then? Anecdotaly I suspect not much. Certainly newspaper headlines about failed government IT projects of late (see, for example The Independent on 9th January 2010: Labour’s Computer Blunders Cost £26bn) would seem to indicate we are still not very good at delivering complex systems.

The interesting thing to observe about the above list of course is that none of these problems are technical in nature, not directly anyway. Instead they are to do with governance and process (or lack thereof) and what you might term “soft” aspects of systems delivery, how we manage and understand what people want. One of the right-brain activities which we IT folk sometimes fail to exercise is “empathy”. Our capacity for logical thought (i.e. left-brain activity) has gone a long way to creating the technological society we live in today. However in a world of ubiquitous information that is available at the touch of a button logic alone will no longer cut the mustard. In order to thrive we need to understand what makes our fellow humans tick and really get beneath their skin and to forge new relationships.

Happily this is not something that is easily outsourced, at least not yet! There is still something we can do as IT professionals therefore in engaging with stakeholders, understanding there wants and needs and trying to deliver systems that meet their requirements that can only be done with direct, personal contact.

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.