creativity

The Three C’s of IT Architects

Peter Cripps architecture, creativity

This is a completely unscientific observation but over the years of being an architect I have observed the following characteristics in people that claim to be members of this profession.  I refer to these as the three C’s of being an IT architect. Some people have only one of these but most have a mix of all three, with maybe one being dominant. The three C’s are: 

  • Creatives – These are the ideas people, that are keen to do new stuff. They are the people that build the solutions that address the business requirements. They have an intimate knowledge of technology (in their particular area of interest or concern) and want to use that technology. If you don’t have these people in your project/team/organisation then nothing will actually get done. The downside of having too much of this attribute is that eventually you have to stop creating and ship something so you need to know when to stop. 
  • Consumers – These are the people that use what the creatives create. Whilst they may not create anything new this type of architect is not without merit. They often combine what others have done in new and innovative ways. We sometimes refer to this activity as reuse, one of the Holy Grails of IT so it is not to be underestimated. If you don’t have these people in your project/team/organisation then chances are the ideas from the creatives will not get fully realised. The downside of having too much of this attribute is that there is a limit to what you can build out of reusing stuff and eventually someone has to come up with some new ideas. 
  • Connectors – These are the people that don’t create or reuse but know people that can do these things and join the two together. Again this is not to be an underestimated skill. After all if a seller cannot find a buyer what’s the point! If you don’t have these people in your project/team/organisation then the two previous types won’t find each other. The downside of having too much of this attribute is that you ain’t going to do anything if all you do is push ideas of others around without creating or reusing things.

From my observations I reckon a ratio of Creatives to Consumers to Connectors needs to be something like 4:2:1.

Incidentally, my guess is that these actually apply to other professions as well but I have even less scientific evidence about those.

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.

V is for Versatilist

Peter Cripps creativity ,

On the IT architecture class that I teach in IBM we have a thing about saying IT architects should be T-shaped. What we mean by this is shown below.

Ideally an architect should have a good range of general skills and at least one deep skill. So an architect might be a good Java programmer for example but also have a broader range of skills including project management, negotiating skills, SOA or whatever.

A Gartner research note I discovered recently called The IT Professional Outlook: Where Will We Go From Here? (from 2005) predicted that by 2011 “70 percent of leading-edge companies will seek and develop “versatilists” while deemphasizing specialists.” It defines a versatilist as someone “whose numerous roles, assignments and experiences enable them to synthesize knowledge and context in ways that fuel business value”. This diagram better shows the versatilist skills therefore:

I like this because not only is the versatilist a V-shaped sort of guy, denoting a broad range of skills at a greater depth of understanding and practice, I believe these skills should be cross-discipline and yes, maybe even consist of right-brain as well as left-brain skills.

As mentioned in a previous post I believe that we architects need not only breadth, to quite a level of depth, but also a good range of skills across all disciplines if we are to come up with new ways of thinking to solve some of the wicked problems out there. Architects should therefore by V(ersatilist), not T-shaped.

Skills for Building a Smarter Planet: A Manifesto

Peter Cripps creativity , ,

IBM is currently doing a big advertising campaign called Smarter Planet. I recently put together a lecture for a group of university students which tried to weave together a number of themes which I am currently interested in:

Here’s my manifesto:

In the 21st century IT professionals must adopt more of a systems thinking approach if they are to solve the wicked problems the world faces. If we are truly going to build a smarter planet then we need a new breed of versatilists who are able to solve these problems.

There are a number of themes here I plan to return to in future posts.

Tim Brown on Design Thinking

Peter Cripps architecture, creativity , , ,

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.

Five Reasons Why Good Photographers Make Good (IT) Architects (or the Other Way Around)

Peter Cripps architecture, comment, creativity ,

In a different life (or maybe even this one, one day) I would have been a photographer and still occasionally dust off my camera to take a few snaps. I recently took to thinking about the traits that IT architects have and decided there were some similarities between them:

  1. A good photographer knows how to use the ideas of others and adapt them accordingly. See here for a wacky adaption of some classic images
  2. A good photographer sees things others don’t by applying interesting or novel views. Here’s an attempt from me:
  3. Photography is both an art and a science. The best photographs come from applying both. See here for a great example.
  4. Don McCullin says “I only use a camera like I use a toothbrush. It does the job.” A good architect knows how to use tools and technology but does not get distracted by them.
  5. You don’t need lots of expensive kit to be a good photographer however when you do want to acquire some shiny new stuff you usually need to convince your sponsor (AKA partner in most cases) of the benefits of the new technology. Architects usually need to convince their sponsor of the business benefits of a new system, not the technical ones. See here for a great exposition of this.