Monday, June 28, 2010

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

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.

Thursday, June 24, 2010

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

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)

Tuesday, June 22, 2010

Are Frameworks Too Constraining and is Chaos the Natural State?

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.

Thursday, June 10, 2010

When Does an Architecture Become a Reference 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

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 points out, 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.

Friday, June 4, 2010

Working with Zuck

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.