Choosing What to Leave Out

April 11, 2012March 22, 2014 Peter Cripps architecture, creativity austin kleon, nokia

In his book Steal Like an Artist, Austin Kleon makes this insightful statement:

In this age of information abundance and overload, those who get ahead will be the folks who figure out what to leave out, so they can concentrate on what’s really important to them. Nothing is more paralyzing than the idea of limitless possibilities. The idea that you can do anything is absolutely terrifying.

This resonates nicely with another article here on frugal engineering or “designing more with less”. In this article the authors (Nirmalya Kumar and Phanish Puranam) discuss how innovation is meeting the needs of the Indian marketplace, where consumers are both demanding as well as budget constrained and how “the beauty of the Indian market is that it pushes you in a corner…it demands everything in the world, but cheaper and smaller.” This article also talks about “defeaturing” or “feature rationalization”, or “ditching the junk DNA” that tends to accumulate in products over time.

As an example of this the most popular mobile phone in India (and in fact, at one point, the bestselling consumer electronics device in the world) is the Nokia 1100. The reason for this device’s popularity? Its stripped down functionality (ability to store multiple contact lists so it can be used by many users, ability to enter a price limit for a call and built-in flashlight, radio and alarm) and low price point make it an invaluable tool for life in poor and underdeveloped economies such as rural India and South America.

For a software architect wishing to make decisions about what components to build a system from there can often be a bewildering set of choices. Not only do several vendors offer solutions that will address the needs there are often many ways of doing the same thing, usually requiring the use of multiple, overlapping products from different vendors. All of this adds to the complexity of the final solution and can end up in a system that is both hard to maintain as well as difficult, if not impossible, to extend and enrich.

Going back to Austin Kleon’s assertion above, the trick is to figure out what to leave out, just focusing on what is really important to the use of the system. In my experience this usually means that version 1.0 of anything is rarely going to be right and it’s not until version 2.0+ that the fog of complexity gradually begins to lift allowing what really matters to shine through. Remember that one of my suggested architecture social objects is the Change Case. This is a good place to put those features of little immediate value, allowing you to come back at a later date and think about whether they are still needed. My guess is you will be surprised at how often the need for such features has passed.

Architecture Work Products as Social Objects

March 23, 2012March 22, 2014 Peter Cripps architecture david johnson, social objects, work products

As architects we clearly need to describe the architectures we are creating. Sometimes what we are trying to describe can be fairly abstract and it helps to have a common and well understood set of work products to describe and facilitate an understanding of the concepts we are trying to get across. I’ve previously talked about how architecture social objects can be used as a communication device that generates conversation and action around the object. This blog post by David Johnson suggests that all social objects have three things in common, which I think further reinforces the usefulness of a well thought out set of architecture social objects. According to Johnson the three things social objects have in common are:

Conversational: people want to talk and have conversations with other people connected with the social object.
Brings People Together: people want to be around other people that are connected with the social object. They feel part of a community, that they belong with each other.
Talk Worthy: people feel the desire to tell other people, who may not know about the social object, so that they, in turn, become part of the community.

Over time I’ve discovered there is a core set of work products that form the social objects which bring people together and can act as conversational pieces for architects to talk about. This is especially important when you have to quickly create a (partial) architecture that shows how a number of software components (both bespoke and off-the-shelf) can work together to address a set of requirements.

It’s especially useful to do this when there is little time to create such solutions, as when you may be responding to an invitation to tender (ITT) from a client for example. At such times requirements are often even more ill defined than usual and time is of the essence if you are to get in your bid by the deadline. There is usually no time for the niceties of ‘proper’ work products; the end game is to create physical view of the architecture which can be used for financial costing and other sizings. However you still need some level of discipline and process if you are to create something that can be understood by everyone. In other words you quickly need to come up with a set of architecture social objects.

Here then is a seven-step approach that is useful for creating social objects that can be discussed amongst architects and stakeholders. All of the social objects in what follows are stripped down versions of the work products we define in The Process of Software Architecting.

Use what requirements you have and create a System Context identifying key actors (especially other systems).
Try to break down what requirements into functional areas, ‘Customer Management’, ‘Facilities Management’, ‘Diary and Calendar Management’ etc.
Draw an Architecture Overview showing the functional areas from 2) as subsystems/large-grain components.
Use the Architecture Overview and match against known patterns to derive the technical subsystems/components. In particular this step should account for any non-functional requirements to qualify your choice of technical components.
Capture Architecture Decisions as to why you chose which components you did.
Create Change Cases that you can play back to the client as a way of validating the approach and further establishing what is out of scope but which the architecture can support.
Validate the whole thing in an Architecture Assessment. This will be used to identify issues and risks associated with the architecture and recommend actions and mitigation strategies to address them.

Whilst I’m not suggesting the above is in any way a substitute for a full and rigorous architecture process it’s definitely better than not following any process and will at least create a basic set of those architecture social objects that can be used to have the right conversations.

Giving Users What They Want (Maybe)

March 20, 2012March 22, 2014 Peter Cripps architecture, creativity apple, henry ford, steve jobs

Tradition has it that users come up with a set of requirements which architects and designers take and turn into “a solution”. That is, a combination of bespoke and off-the-shelf, hardware and software components, that are assembled in such a way they address all the requirements (non-functional as well as functional). Another point of view is that users don’t actually know what they want and therefore need to be guided toward solutions they never knew they needed or indeed knew were possible. Two famous proponents of this approach were Henry Ford who supposedly said:

If I had asked people what they wanted, they would have said faster horses.

which is debunked here and of course Steve Jobs and Apple whose “Eureka” moments continue to give us gadgets we never knew we needed. As Adrian Slywotzky points out here however, the magic that Jobs and Apple seem to regularly perform is actually based on highly focused and detailed business design, continuous refinement through prototyping and a manic attention to the customer experience.In other words it really is 90% perspiration and 10% inspiration.

One thing that both Henry Ford and Steve Jobs/Apple did have in common was also a deep understanding of the technology in their chosen fields of expertise and, more importantly, where that technology was heading.

If, as an architect, you are to have a sensible conversation with users (AKA customers, clients, stakeholders et al) about how to create an architecture that addresses their needs you not only need a good understanding of their business you also need a deep understanding of what technology is available and where that technology is heading. This is a tall order for one persons brain which is why the job of an architect is uniquely fascinating (but also hard work). It’s also why, if you’re good at it, you’ll be in demand for a while yet.

Remember that, even though they may not know it, users are looking at you to guide them not only on what the knowns are but also on what the unknowns are. In other words, it’s your job to understand the art of the possible, not just the art of the common-or-garden.

Making Smart Architecture Decisions

March 13, 2012March 22, 2014 Peter Cripps architecture architecture decisions, seth godin, social objects, system of record

Seth Godin whose blog can be found here, posted a wonderful entry called The extraordinary software development manager yesterday which contains some great axioms for managing complex software projects, the last of which is something I wish I’d written! Here is what it says:

Programming at scale is more like building a skyscraper than putting together a dinner party. Architecture in the acquisition of infrastructure and tools is one of the highest leverage pieces of work a tech company can do. Smart architecture decisions will save hundreds of thousands of dollars and earn millions. We’ll only make those decisions if we can clearly understand our options.

As I’ve said elsewhere architecture decisions are one of the most crucial social objects to be exchanged between stakeholders on a software development project. For a very thorough description of what architecture decisions are and how they can be captured see the article Architecture Decisions: Demystifying Architecture by Jeff Tyree and Art Akerman. However you don’t need to make every decision to such a precise level of detail. At a minimum you just need to make sure you have looked at all options and assumptions and have captured the rationale as to why the decision was made. Only then can you move forward reasonably safe in the knowledge that your decisions will stand the test of time and, as a bonus, will be transparent for all to see and to understand the rationale behind them.

Good architecture decisions will form part of the system of record for the project and the system itself, once it is built. They will allow future software archeologists to delve deeply into the system and understand why it is the way it is (and maybe even help fix it). They also help newcomers to the project understand why things are the way they are and help bring them up to speed more quickly on the project. Finally, and possibly most importantly of all, they stop others making different decisions later on with possibly great financial implications to the project. If you can read and understand the rationale behind why a decision was made you are less likely to overturn the decision or ignore it all together.

It’s the NFR’s, Stupid

February 29, 2012March 23, 2014 Peter Cripps architecture analytics, cloud, ethics, non functional requirements, philippe kruchten

An apocryphal (to me at least) tale from Forbes that provides a timely reminder of the fact that even in this enlightened age of clouds that give you infrastructure (and more) in minutes and analytical tools that business folk can use to quickly slice and dice data in all manor of ways, fundamentals, like NFRs, don’t (or shouldn’t) go out of fashion.According to Forbes the US retailer Target figured out that a teenager was pregnant before her parents did. Target analysed the buying behaviour of customers and identified 25 products (e.g. cocoa-butter lotion, a purse large enough to double as a diaper bag and zinc and magnesium supplements) that allowed them to assign each shopper a “pregnancy prediction” score. The retailer also reckoned they could estimate the due date of a shopper to within a small window and so could send coupons timed to very specific stages of a pregnancy. In the case of this particular shopper Target sent a letter, containing coupons, to a high-school pupil whose father opened it and was aghast that the retailer should send coupons for baby clothes and cribs to a teenager. The disgruntled father visited his local Target store accusing them of encouraging his daughter to get pregnant. The manager of the store apologised and called the father again a few days later to repeat his apology. However this time the father was somewhat abashed and said he had spoken to his daughter only to find out she was in fact pregnant and was due in August. This time he apologised to the manager.

So, what’s the lesson here for architects? Here’s my zen take:

Don’t assume that simply because technology seems to be more magical and advanced you can ignore fundamentals, in this case a persons basic entitlement to privacy.
With cloud and advanced analytics IT is (apparently) passing control back to the business which it has done in a cyclical fashion over the last 50 – 60 years (i.e. mainframe -> mini -> PC -> client-server -> browser -> cloud). Whoever “owns” the gateway to the system should not forget they should have the interests of the end user at heart. Ignore their wants and needs at your peril!
Legislation, and the lay-mans understanding of what technology can do, will always lag advances in technology itself. Part of an architects role is to explain, not only the benefits of a new technology, but also the potential downside to anyone that may be impacted by that technology. In the connected world that we now live in that can be a very large audience indeed.

Part of being an architect is to talk to everyone to explain not only your craft but also your work. Use every opportunity to do this and reject no one who might want to understand a technology. As Philippe Kruchten says in his brilliant interpretation of Lao-Tsu’s Tao Te Ching for the use of software architects:

The architect is available to everyone and rejects no one.
She is ready to use all situations and does not waste anything.
This is called embodying the light.

Make sure you repeatedly “embody the light”.

Architecting Out Complexity

January 5, 2012March 24, 2014 Peter Cripps architecture architecture thinking, complex systems, fred brooks, ray ozzie

Complexity kills. Complexity sucks the life out of users, developers and IT. Complexity makes products difficult to plan, build, test and use. Complexity introduces security challenges. Complexity causes administrator frustration.

So said Ray Ozzie ex-Microsoft Chief Software Architect and creator of Lotus Notes.

Complexity, or more precisely, overly complicated systems (not to be confused with complex systems) is one of the key anti-patterns architects must continuously fight against. Complexity is caused not just by adding additional and unwanted functionality (although that certainly does not help) but also by muddled architectural thinking as well as poorly made architectural decisions. Here’s the real problem though, the initial architecture of almost any system, unless it borrows very heavily from other, similar, architectures will rarely be without complexity. There will almost always be refinements that can be made, over time, that remove complexity and make for a cleaner and more streamlined design. Sometimes you may even need to throw away the initial architecture and start again, using what you have learnt from the initial architecture to take out complexity. Frederick Brooks (author of The Mythical Man Month) famously said of software designs “plan to throw one away, you will anyway“.

The other problem with complexity in systems is that it tends to increase over time due to software entropy. As more changes are made, some not envisaged by the architect because change cases were not adequately thought through, a system naturally becomes more complicated and harder to maintain. It almost seems that the lifecycle of a system could be represented by the complexity curve in the diagram below.

Complexity does not just apply to systems, it also applies to whole styles of architecture. Cloud computing would still seem to be fairly early on in the complexity curve in this respect. Cloud computing is almost the ultimate in information hiding. Just put everything in the cloud and get what you want when you want it. If you’re inside the cloud looking out however you need to deal with a whole lot of pain to create that outward facing simplicity. If you’re a cloud architect therefore you need to understand and design for that complexity otherwise over time our clouds will become weighed down with out of date junk that no one wants. This is definitely a topic I’ll be returning to over the course of 2012.

Parkinson’s Law of Triviality (Applied to Architecture)

November 17, 2011March 26, 2014 Peter Cripps architecture anti-pattern, parkinsons law

Parkinson’s Law of Triviality (as proposed by C. Northcote Parkinson in 1957) is that people give disproportionate weight to trivial issues. Parkinson gives as an example a hypothetical (planning) committe deliberating on the building of a nuclear power plant and a bicycle shed. Parkinson stated that “the time spent on any item of the agenda will be in inverse proportion to the sum involved.” Clearly a nuclear reactor is vastly expensive and complicated and the average person is unlikely to understand it because it is so far outside the realms of their daily experience. A bike shed, on the other hand, everyone understands (or thinks they do, which can be even more dangerous). The result is that people will be reluctant to discuss for long the nuclear reactor either because they assume those working on it understand it or because they are to fearful of making themselves look foolish in front of the experts. The bike shed however can result in endless discussions because everyone involved wants to add their “feature” and show that they have contributed. While discussing the bike shed, debate rages over what the best choice of roofing should be, whether there should be windows, whether it should be fully enclosed with walls and a door etc, etc rather than whether the shed is a good idea or not.Parkinson’s Law of Triviality is something that frequently creeps into architecture discussions. When requirements are being discussed and how best to realize them architecturally it is frequently the case that when the domain under discussion consists of parts that are familiar and ones that are not it is the former that will often receive inordinate amounts of discussion whereas the latter do not (but usually should). A good example to illustrate this is that of e-commerce systems. Because most people have used such systems everyone will have an opinion on the bits they are familiar with (the actual look and feel of the shopping experience for example, do you call it a shopping basket or a trolley, do you allow goods to be placed in the basket before you have logged in or registered and so on). The part of the system that deals with payment however (i.e. that goes off in the background and does credit checks etc) or checking stock level is not seen so people will probably have less of an opinion on it. This part, at least as far as the web site owner is concerned, is the most important however because if that does not work he will lose money. Worse however is if the “payments specialist” says that this is the way payments will work, and no one else feels they have the expertise or authority to challenge her. Doing something because that’s the way we always do it is an example of the Golden Hammer anti-pattern and does not always result in the most innovative or creative new systems.

So how to protect against falling foul of Parkinson’s Law of Triviality?

Good architects need to develop deep domain knowledge and know how to, and be fearless in doing so, challenge expert opinion. Frequently appearing foolish by challenging the blindingly obvious is a small price to pay for occasionally highlighting a problem which everyone else overlooked because they were following conventional wisdom.
Ensure complex problems receive proportionately more discussion than simple ones. In other words cut the discussion of addressing the simple problem sooner to allow time to discuss the complex ones. Better still if in a meeting there are several problems to be discussed prioritise them by complexity and start with the most complex first. Leaving simpler ones till the end means you can rush those through when everyone gets tired or you are out of time.
Recognise that everyone has an equal say and it is often the people who know least about the problem that ask the daft, but hard, questions. This of course would seem to go against number 1. If everyone is an expert doesn’t that mean no one will be naive enough to ask the simple but challenging questions? No. A good team has a diverse mix of skills, knowledge and opinions and should allow everyone to comment.
Leave your ego at the meeting room door and do not use your relative position in the hierarchy of the company to trivialise other peoples ideas or prevent constructive discussion because it is not “going your way”.
Finally capture all decisions in a systematic way (recording at the very least what the decision was, what options were discussed, the rationale for choosing the one you did and any related decisions or implications).

What Can Architects Learn from Steve Jobs

November 8, 2011March 26, 2014 Peter Cripps architecture apple, henry ford, ibm, microsoft, steve jobs, walter isaacson

I’ve just finished reading Steve Jobs by Walter Isaacson. In case there is anyone out there who doesn’t know it yet, this is the authorised biography that Jobs asked Isaacson to write which was completed a few weeks before Jobs untimely death aged 56 last month. Jobs insisted that Isaacson would have complete control over the contents of the book saying he would not even read it before it was published adding “I don’t have any skeletons in my closet that can’t be allowed out”.Jobs is clearly a very complex personality, on the one hand a creative genius whose zen like focus on simplicity and efficiency helped create some of the most beautiful and useful gadgets of our time (some of which we never even knew we needed) whilst on the other he was a bully and a tyrant who knew exactly how to “size people up, understand their inner thoughts, and know how to relate to them, cajole them, or hurt them at will”. One of jobs girl friends, who later went on to found a mental health resource network in California, even went so far to say that she thought Jobs suffered from Narcissistic Personality Disorder (NPD) in which the individual is described as being excessively preoccupied with issues of personal adequacy, power, prestige and vanity.

Whilst it is to be hoped that NPD is not a prerequisite for being a software architect Jobs did have vision and understanding of IT that we as architects can learn from. Six big ideas that stand out in this respect are:

Engineering matters. When jobs met with President Obama in 2011 he implored the President to reform the US education system and to create more engineering students. Jobs said “if you could educate these engineers we could move more manufacturing plants here”. Whilst there was always an uneasy tension between engineering and design at Apple Jobs recognised and valued the importance of there being an engineering led rather than sales led team at the top of the company berating companies like Microsoft (under Balmer), IBM (under Akers) and HP (under their last several CEOs) for putting sales people in charge rather than engineers. For software architects, engineering clearly translates to being intimately knowledgeable with the technology you are using, knowing how to put the working parts together. The best architects I know are passionate about technology.
Artistry and design matters just as much as engineering. This is a theme that Jobs emphasises over and over again. From when he dropped out of college and instead took a course on calligraphy to his sometimes maniacal focus on the smallest details of design to make the product as satisfying and aesthetically pleasing as possible. He even emphasized that circuit boards, which no one would ever see once the product was fully assembled, should be laid out in as clean and uncluttered was as possible. It is this aspect of design that most matters for architects. Provided that functionally a system does what it is meant to do within the required constraints and system qualities one could argue it does not matter how messily the software is assembled. Whose going to see it anyway? This misses the point though.Great design, as opposed to just good enough design, means the system will be easier to maintain, take less effort to learn and generally be more enjoyable for those that need to carry on working on it once the architects and developers have moved on.
Simple is better than complex. Apple had a design mantra: “Simplicity is the ultimate sophistication” or as Jobs said “very simple, and we’re really shooting for Museum of Modern Art quality”. Jobs felt that design simplicity should be linked to making products easy to use.So much of the software that we create today is far too complex and feature rich and as a result is very hard to use. People will often say that it has to be like that because just look at all the features you are getting. Unfortunately a lot of the time many of those features are not needed but add to the general bloat of the systems we build making them hard to use as well as difficult to maintain. Sadly building a complex system is often easier than building a simple one and it is not many architects that see value in stripping out functionality rather than adding it.
An unremitting focus on detail is key to creating a great product. Jobs was unique in that he was able to hold both the big picture view as well as zooming in to fine details. He would often sweat over the smallest detail until he was satisfied it was just right. This could be anything from the colour of a screw on the back plate of the iPod to the angle of the bevel on the iPad to make someone want to pick it up. This capacity for holding both the big picture view whilst also being able to zoom right down and question low level details is probably one of the hardest things architects have to do but being able to do so gives a definite advantage and enables greater integrity as well as better execution of vision.
Customers don’t always know what they want. In September 1982 when Jobs and his team were designing the original Macintosh he held a retreat for the Mac team near Monteray where he gave a presentation on his thoughts for the Mac. At the end someone asked whether or not they should do some market research to find out what customers wanted. “No”, replied Jobs, “because people don’t know what they want until we’ve shown them”. He then pulled out a device the size of a desk diary and flipped it open, it turned out to be a mock-up of a computer that could fit into your lap with a keyboard and screen hinged together like a notebook. “This is my dream of what we will be making in the mid- to late eighties”, Jobs said. Apple supposedly never did do any market research preferring to follow the Henry Ford approach who said he never asked what people wanted because they would have just asked for a better horseless carriage. Whilst it is probably the case that people can often see how to make incremental improvements to products they usually cannot see how to make disruptive changes that introduce a who new way of doing things, possibly making everything that went before it redundant. It is the job of the architect to show what is in the realms of the possible by creating new and innovative systems.
Putting things together in new and creative ways is sometimes more important than inventing things. Jobs was not the first to market with an MP3 player, a mobile phone or a tablet computer. Others had already innovated and built these things. What Jobs and Apple did were to tweak things that already existed. As Isaacson says “he had noticed something odd about the cell phones on the market: They all stank, just like portable music players used to”. Jobs applied his design skills to these and came up with a (far) better product and in fact a whole new platform as well (i.e. the computer as the digital hub. Architects to need to learn that its often putting together existing components in new and innovative ways that really counts and gives a competitive and business advantage.

Software Architecture Zen

The musings of a technorealist

architecture