Should We Ask Can We Fix It or State We Can?

Peter Cripps comment ,

In a recent Sunday Telegraph column author Dan Pink draws on recent scientific research which suggests that contrary to popular belief  “declarative” self-talk (I will fix it!) may not be as effective as “interrogative” self-talk (Can I fix it?) when it comes to solving problems. He also draws inspiration from that legendary management guru Bob the Builder.

Lisa Gansky (a serial entrepreneur) says that business leaders in general, and entrepreneurs in particular face an occupational hazard that she calls “breathing your own exhaust”. Gansky goes on to say:

“When you create something, you can fall in love with it and aren’t able to see or hear anything contrary. Whatever comes out of your mouth is all you’re inhaling. But when you ask a question – Will I? – you’re creating an opening. You’re inviting a conversation – whether it’s self-conversation or a conversation with others.”

So what’s this got to do with software architecture I hear you ask? The need for solving problems, especially wicked ones where there is no definitive formulation and maybe even no immediate or ultimate test of a solution, needs an approach which is different from the “all guns blazing” we can fix anything usual style of management consultants. Some problems are so hard they may never have a fully compete solution, just a series of compromises which hopefully result in you being in a better place than you were at the start. Maybe a little humility at the beginning will help in the setting of expectations therefore and reduce the distance you have to fall if you don’t deliver to those expectations.

In the meantime here are some videos to provide you with some inspiration around the fixing it theme:
Can We Fix It – Bob the Builder
Yes We Can – Barak Obama
Fix You – Coldplay (just in case it’s you that needs fixing)

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.

Art, Creativity and the Tyranny of the Timesheet

Peter Cripps comment , , , ,

Apparently lawyers are some of the glummest groups of professionals out there! One of the reasons for this is the very nature of their profession; it’s usually a “zero-sum” game, if somebody wins someone else loses (and in extreme cases loses their life). Another theory, put forward by Dan Pink in his book Drive – The Surprising Truth About What Motivates Us, is that lawyers have to deal with one of the most “autonomy crushing mechanisms imaginable – the billable hour”. Lawyers have to keep careful track of every hour they spend, sometime to the level of granularity of six minute time chunks, so they can bill their time to the correct client. As a result their focus inevitably shifts to from the quality of the work they do (their output) to how they measure that work (its input). Essentially a lawyers reward comes from time, the more hours they bill, the higher their (or their legal practices) income. In today’s world it is hard to think of a worse way to ensure people do high quality and creative work than making them fill in a timesheet detailing everything they do.

Unfortunately the concept of the billable hour is now firmly embedded into other professions, including the one I work in, IT consulting. As IT companies have moved from selling hardware to software that runs on that hardware and then to providing consulting services to build systems made up of hardware and software they have had to look for different ways of charging for what they do. Unfortunately they have taken the easy option of the billable hour, something that the company accountants can easily measure and penalise people for if they don’t achieve their billable hours every week, month or year.

The problem with this of course is that innovation and creativity does not come in six minute chunks. Imagine if the inventors of some of the most innovative software architecture (Tim Berners-Lee’s world-wide web or Mark Zuckerberg’s Facebook) had to bill their time. When such people wake up in the middle of the night with a great idea that would solve their clients business problem what’s the first thing they reach for: a notebook to record the idea before its gone or a spreadsheet to record their time so they can bill it to the client!

As Dan Pink says, the billable hour is, or should be, a relic of the old economy where routine tasks (putting doors on cars, sewing designer jeans or putting widgets into boxes) had tight coupling between how much effort goes in and the work that comes out. In the old economy where a days work equaled a days pay and you were a day laborer you essentially sold out to the highest bidder. Isn’t what we do worth more than that? As Seth Godin points out “the moment you are willing to sell your time for money is the moment you cease to be the artist you’re capable of being”.

But what’s the alternative? Clearly IT consulting firms need to be able to charge clients for their work; they’re not charities after all. Here are my thoughts on alternatives to the tyranny of the timesheet which enable the art and creativity in building IT systems to flourish.

  1. Start with the assumption that most people want to do good work and incentivise them on the work products they create rather than the work inputs (time recorded).
  2. Recognise that creativity does not fit nicely into a 9 – 5 day. It can happen at any time. Scott Adams (creator of Dilbert) has his most creative time between 5am and 9am so is just finishing his work when the rest of us are starting. Creative people need to be allowed to work when they are at their most creative, not when company accountants say they should.
  3. When charging clients for work agree on what will be delivered by when and then build the right team to deliver (a team of shippers not time keepers). Of course this gives company lawyers a nightmare because they get involved in endless tangles with clients about what constitutes a deliverable and when it is complete (or not). Maybe giving lawyers a creative problem to solve will cheer them up though.
  4. Give people time-out to do their own thing and just see what happens. Google famously give their employees 20% time where they are allowed to spend a day working on their own projects. A number of google applications (including gmail) were invented by people doing their own thing.
  5. Allow people to spend time having interactions outside their immediate work groups (and preferably outside their company). Innovative ideas come from many sources and people should be allowed to discover as many new sources as possible. If someone wants to spend half-a-day walking round an art gallery rather than sitting at their desk, why not? Frank Gehry allegedly got his idea for the shape of the Guggenheim Museum in Bilbao from Picasso’s cubist paintings.

In the new economy, the conceptual age where creativity and versatilism is the order of the day the timesheet should be firmly assigned to the shredder and people should be treated as innovaters not just cogs in the big corporate machine.

Working with Zuck

Peter Cripps comment ,

In this article Facebook software engineer Andrew Bosworth describes what its like to work with the founder and architect of Facebook, Mark Zuckerberg (‘Zuck’). The attributes that Bosworth ascribes to Zuckerberg, that by implication are at least partly the reasons for his galactic success, are ones which I believe all architects should aspire to. Here are the four attributes with my spin on how I think they apply to architects in general:

  1. Zuck expects debate. A good architect is not a dictator but should expect, and be happy to participate in, debate. Be open to new ideas and don’t think you have all the answers. At the same time be robust in pushing back on any ideas to test out peoples thinking thoroughly. Be aware of people who play Devil’s Advocate and who argue just to be heard or are negative without proposing viable, alternative solutions.
  2. Zuck isn’t sentimental. It’s sometimes easy to be too wedded to an idea or your favourite technology. Be prepared to scrap these and to throw things away if they no longer meet the requirements or something better has come along. As Bosworth says of Zuckerman he is “fearless about disrupting the status quo and tireless in his pursuit of building the right thing, even in an ever-changing landscape”.
  3. Zuck experiences things contextually. As architects we often talk about ideas very abstractly and prefer to talk in generalities rather than specifics. Bad idea! A good architect (and indeed architecture) should be firmly grounded in reality and be backed up by actual products, prototypes, even working code! The best way of convincing someone of your idea is to build something that you can give them to play with.
  4. Zuck pushes people. People can often do more than they think (sometimes in less time than they think as well). The important thing is to be focussed on the problem and not the distractions that your job (as opposed to your work) may bring.

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.

On Being an Artitect

Peter Cripps architecture ,

My mum, who just turned 85 this month, mispronounces the word architect. She says “artitect” where a “t” replaces the “ch”. I’ve tried to put her right on this a few times but I’ve just finished reading the book by Seth Godin called “Linchpin – Are You Indispensable?” and decided that actually she’s probably been pronouncing the word right after all. I’ve decided that the key bit she’s got right and I (and all of the rest of us haven’t) is the “art” bit. Let me explain why.

The thrust of Seth’s book is that to survive in today’s world of work you have to bring a completely different approach to the way you do that work. In other words you have to be an artist. You have to create things that others can’t or won’t because they just do what they are told not what they think could be the right creative approach to building something that is radically new. Before I proceed much further with this thread I guess we need to define what we mean by artist in this context. I like this from Seth’s book:

An artist is someone who uses bravery, insight, creativity and boldness to challenge the status-quo. And an artist takes it personally.

As to what artists create:

Art isn’t only a painting. Art is anything that is creative, passionate and personal.

I’d also add something like “and changes the world for the better” to that last statement otherwise I think that some fairly dodgy activities might pass for art as well (or maybe even that is my lizard brain kicking in, see below).

Of course that’s not to say that you shouldn’t learn the basics of your craft whether you are a surgeon, a programmer or a barista in a coffee shop. Instead you should learn them but then forget them because after that they will hold you back. Picasso was a great “classical” artist. In other words he knew how to create art that would have looked perfectly respectable in traditional parts of the art galleries of the world where all the great masters work is displayed that follows the literal interpretation of the world. However once he had mastered that he threw the rule book out completely and started to create art that no one else had dared to do and changed the art-world forever.

So an artitect (rather than an architect) is someone who uses creativity, insight, breadth of vision and passion to create architectures (or even artitectures) that are new and different in someway that meet the challenges laid down for it, and then some.

Here are the five characteristics that I see a good artitect as having:

  1. Artitects are always creating new “mixes”. Some of the best IT architects I know tell me how they are creating new solutions to problems by pulling together software components and making them work together in interesting and new ways. Probably one of the greatest IT architects of all time – Tim Berners-Lee who invented the world-wide web – actually used a mix of three technologies and ideas that were already out there. Markup languages, the transmission control protocol (TCP) and hypertext. What Tim did was to put them together in quite literally a world-changing way.
  2. Artitects don’t follow the process in the manual, instead they write the manual. If you find yourself climbing the steps that someone else has already carved out then guess what, you’ll end up in the same place as everyone else, not somewhere that’s new and exciting.
  3. Artitects look at problems in a radically different way to everyone else. They try to find a completely different viewpoint that others won’t have seen and to build a solution around that. I liken this to a great photograph that takes a view that others have seen a thousand times before and puts a completely different spin on it either by standing in a different place, using a different type of lens or getting creative in the photo-editing stage.
  4. Artitects are not afraid to make mistakes or to receive ridicule from their peers and colleagues. Instead they positively thrive on it. Today you will probably have tens or even hundreds of ideas for solutions to problems pop into your head and pop straight out again because internally you are rejecting them as not been the “right approach”. What if instead of allowing your lizard brain (that is the part of your brain that evolved first and kept you safe on the savanna when you could easily get eaten by a sabre-toothed tiger) to have its say you wrote those ideas down and actually tried out a few? Nine out of ten or 99 out of a 100 of them might fail causing some laughter from your peers but the one that doesn’t could be great! Maybe even the next world-wide web?
  5. Artitects are always seeking out new ideas and new approaches from unlikely places. They don’t just seek out inspiration from the usual places that their profession demands but go to places and look to meet people in completely different disciplines. For new ideas talk to “proper” artists, real architects or maybe even accountants!!!

Perhaps from now on we should all do a bit less architecture and a bit more artitecture?

Architecture vs. Design

Peter Cripps architecture , , ,

Yes it’s that old knotty problem again! Over at gapingvoid.com Hugh MacLeod is fond of using Venn diagrams to illustrate overlapping concerns so here’s one that I recently used for addressing the eternal architecture versus design debate that was the source of much discussion at a recent Architecture Thinking class I was giving.

As I remember it the discussion went something like this:

  • Student: So what’s the difference between architecture and design? It seems from what you’re saying its just a matter of scale?
  • Me: Whilst its true to say that architecture addresses the major components of the system, rather than the detail, it’s more than that. The architecture is the bridge between the “what” (that is the requirements) and the “how” (that is the design).
  • Student: Yeah but isn’t that we usually call “high-level design”.
  • Me: Not really. Grady Booch says: “All architecture is design but not all design is architecture”. (I cheated and looked up this quote afterwards and found that Booch goes on to say “architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.”). In my experience high-level design is just the the view that allows the complete system to be represented on one page.
  • Student: I still don’t see what the difference really is.
  • Me: Okay, here’s the real difference for me (at this point I draw the above Venn on a flip-chart). As well as defining the structure of the system, architecture must also embrace the “what” and the “how” of that structure.  The “what” in this context is the requirements (functional and non-functional) and so architecture involves reasoning about and resolving these sometimes conflicting requirements. It’s about addressing those architecturally significant requirements (the “what”) that will drive (and constrain) the “how” (the design).

Now, if I was drawing this again (and maybe I’ll do this next time) I would actually draw a third overlapping circle which I’d label the “why”. This is where we’d capture the rationale for why we make the (architectural) decisions we do.

Thanks Hugh, this is a neat way of explaining the way things are!

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.