Software Zen and the Art of Versatilism

Peter Cripps architecture ,

In my other blog which I run jointly with David Evans of Koan Solutions we explore what it is to be a versatilist and some of the attributes such people need to have or acquire. Following on from a previous post on the Top 10 Success Secrets of Software Architects here are five more “softer” attributes that software architects might find useful, all link to our versatilist blog.

  1. Software architecture is not so much about what you create as what you want to change. See What do we do for a living?
  2. In creating solutions, of any kind, making the right connections is all important. See Making the right connections.
  3. Innovation comes when there’s an intersection between the arts and the sciences. See And one more thing…
  4. Whatever you are working on right now…choose at least three other ways to perceive it. See Perceptual positions.
  5. Sometimes a reference point just encourages us to keep our worldview, our biases, our grudges and our affections. try losing your reference point. See Losing your reference points.

Top 10 Success Secrets for Software Architects

Peter Cripps architecture ,

Peter Eeles, my co-author of The Process of Software Architecting, has a great presentation called  Top 10 Success Secrets for Software Architects which summarises nicely the attributes a successful architect needs to have and also covers the key points from our book. Briefly these are:

Successful Architects… For example they…
1 Understand end-to-end development. Follow a repeatable process.
2 Understand their role. Understand what an architecture is. Understand what an architect does. Understand the benefits of architecting.
3 Manage risk and manage change. Derive their architectures iteratively.
4 Communicate with stakeholders. Document their architectures.
5 Reuse assets. Embrace different types of assets.
6 Right-size their involvement. Select relevant viewpoints.
7 Influence the requirements. Ensure tradeoffs are negotiated.
8 Derive solutions from business needs. Produce business-driven architectures.
9 Refine solutions based on technology. Realize architectures in available technology.
10 Appreciate the broader context. Align their work with the “bigger picture”.

Peter presented this, with more detail around the attributes and examples, on a public call today. For a replay of the presentation go here. The slides are on slideshare here.

What Business Leaders Want

Peter Cripps comment ,

I’m not a big fan of Mel Gibson (in fact, not a fan at all) but this week have been reminded of the film What Women Want in which he played the lead role. For those who have not seen it (and I’m not recommending it by the way) the film revolves around a chauvinistic executive (Gibson) who, after an accident, gains the ability to hear what women are really thinking. This reminder came about during a conference I have just attended on the role that architects play (or more to the point, should be playing) in industry today. I guess the conference could have been called: What business leaders want (from us architects).

Here’s something I drew during one of the sessions showing the dichotomy we face when trying to build and deliver solutions to a business whose key drivers are less cost, more value.

The perception is that value is only obtained if solutions can be built quickly and cheaply. To a business this usually means within a financial year (or less). For an architect bought up on the importance of delivering integrity and solutions that adhere to best practice and standards that equates to “fast and dirty” which gives us the black curve. To be clear, value is what the business want, which often comes at the cost (in the eyes of the architect) to both their, and that of the systems they are building, integrity. The “trick” then is how to deliver both integrity and value (i.e. the green line)? Here’s my take:

  1. Value can be delivered quickly but only if its done in increments. Plan to deliver something quick (within a financial quarter) but not dirty.
  2. Create a hassle map and focus on the big and nasty hassles first.
  3. Don’t throw out everything you’ve learnt about architectural integrity but instead learn to focus on what matters for the short term. For example architecting for every possible change case may not be relevant if the entire nature of the business is likely to change within the lifetime of the system. Maybe throwing out and staring again is actually an option.
  4. Adopt a “bring you own” rather than “build your own” philosophy. Learn how to prove the business value of bringing rather than building.
  5. Do build for scaleability. Be optimistic that the business will flourish and require more not less of your solution. Take advantage of cloud technology to smooth temporary blips in workload.

These were five things I thought of straight away, there must be loads more (tell me). What is clear is that in troubled times such as these, we must look at adapting our approach to building systems so that we deliver measurable business value more quickly than ever, or we won’t be around to enjoy the next Mel Gibson tale!

Hassle Maps and Expert Integrated Systems

Peter Cripps architecture , , , , , ,

In his book Demand: Creating What People Love Before They Know They Want It the business thinker and management consultant Adrian Slywotzky defines the concept of a Hassle Map thus:

Hassle Map (HA-sul map) noun 1. a diagram of the characteristics of existing products, services and systems that cause people to waste time, energy, money 2. (from a customer’s perspective) a litany of the headaches, disappointments and frustrations one experiences 3. (from a demand creator’s perspective) an array of tantalising opportunities.

Documenting, either literally or mentally, the hassle map for a product, service, system or process is the first step on the way to improving it and to creating something that people will love and want. A key part of the hassle map is finding out what users of an existing product or service find most annoying and stop them from buying it in great quantities. For Steve Jobs this was the inadequacies of existing mobile phones, for Reed Hastings CEO of Netflix it was the ‘hassle’ of having to walk to the video store to rent a movie (and being fined when you forgot to take it back on time), for Jeff Bezos, founder of Amazon, it was not just building an e-reader device (the Kindle) with a great interface but also one which had a massive catalogue of books that could be downloaded in ‘one-click’. The list goes on.

One way of drawing up a hassle map is to think of what the world would be like without the hassle; a sort of idealized view of life. A hassle map, consists of a number of hassles and for each, a view of what life would be like without the hassle. I once worked with a client who was fond of using the phrase “imagine a world where…” Well, the solution bit of a hassle map is the world where that hassle no longer exists.

Expert integrated systems, as manifested by IBM’s PureFlex and PureApplication Systems, are an attempt at addressing the hassle maps currently felt by businesses when building IT systems. Here are 10 hassles that these systems are trying to overcome.

Hassle Solution
IT increasingly seen as a constraint on business innovation rather than an enabler. Expert integrated systems enable delivery of new capabilities, faster allowing IT resources to be moved from ‘running the business’ to ‘changing the business’.
Software and hardware has to be ordered separately taking days or weeks to arrive. System arrives as a single integrated hardware and software package, ready to be turned on.
Components arrive as a “bag of parts” requiring integration and optimization. Components are pre-installed, integrated and optimized.
Specification of deployment environment requires specialist skills, can be brittle and error prone. ‘Patterns of expertise’ that capture proven best practices for complex tasks learned from decades of client and partner engagements that are captured, lab tested and built into the system.
Systems require time-consuming optimization by experts on site. Pre-optimized by experts in the factory before shipment.
Deployment time takes weeks. Deployment time takes minutes.
Multiple management consoles for each middleware software product. Single point of management across all middleware products.
Lack of dynamic elasticity results in cumbersome re-allocation of resources. Repeatable self service provisioning, integrated and elastic application and data runtimes and application-aware workload management.
Takes weeks or months for a development or test environment to be built plus non-standard configurations can cause errors and delay production deployments by weeks. Self service development, test and production environments, provisioned, secured and managed in adherence to corporate policies through customizable pre-defined patterns.
Upgrades involve days of downtime. Zero downtime upgrades.

Of course ‘hassles’, are really only high-level requirements stated in a way that business folk really care about, that is what is causing them pain. These are the right sort of requirements and the sort we IT folk must take most notice of if we are to build systems that solve ‘real-world’ business problems.

The Changing Nature of Use Cases

Peter Cripps comment , ,

It might be just me but I have detected a subtle, but significant, change in the meaning of the term use case of late. Something I have found I’ve been going along with but not without feeling slightly uncomfortable whilst doing so. The two definitions I’ve always used for use cases, namely a business use case and system use case come from Alistair Cockburn’s excellent and pretty much definitive guide: Writing Effective Use Cases (shame on you if this is not in your library).

A business use case is one in which the design scope is business operations. It is about an actor outside the organisation achieving a goal with respect to the organisation. The business use case often contains no mention of technology, since it is concerned with how the business operates.

A system use case is one in which the design scope is the computer system to be designed. It is about an actor achieving a goal with the computer system; it is about technology.”

For a discussion on the differences see this blog post. Ivar Jacobson, the person who pretty much invented the term ‘use case’, defines it in the following way:

When a user uses the system, she or he will perform a behaviorally related sequence of transactions in a dialogue with the system. We call such a special sequence a use case.

The way in which I am increasingly seeing use case being used is in a more informal, or less precise way, which is best described in terms of how I actually hear them being used. Here are some examples:

  • I need to understand the use case(s) for how we would use that product.
  • Is that a use case our operations people would support?
  • We need to run some use cases through that solution to test out some of the assumptions.
  • That use case calls for a larger number of users than we had envisaged.

In all of these examples the term ‘use case’ is pretty much synonymous with the term ‘requirement’. The scope may be a product, a system, a solution or an organisation and the actor may or may not be clearly identified. The use cases may imply some function of those entities or some quality (such number of users in the last example above).

Does this matter? At first the purist in me said it did. A use case has to have a well defined actor and a clearly stated set of ‘steps’ that actor performs when interacting with the system or organisation. However on reflection I’ve become slightly more relaxed about it on the basis that:

  • Any term which becomes a common, de-facto currency of understanding is better than not having one.
  • Adding the prefix ‘system’ or ‘business’ still gives us the more formal definitions most architects (business, solution or application) would recognise) so why not relax the use of the term when it does not have one of these prefixes?

Entering into the spirit of this ‘relaxed’ use of the term here are a set of use cases I’ve recently used when trying to articulate some of the uses of ‘Big Data’.This maps use cases onto two of the three so called “Big Data 3-V’ framework” (velocity, variety and (missing on here) volume).

Each of the boxes represents a ‘use case’ (no prefix) which has an informal description as in the following example.

Use Case: Social media analysis: Although basic insights into social media can tell you what people are saying and how sentiment is trending, they cannot answer what is ultimately a more important question: Why are people saying what they are saying and behaving the way they are behaving? Answering this type of question requires enriching the social media feeds with additional data residing in other enterprise systems. In other words, linking behaviour, and the driver of that behaviour, requires relating social media analytics back to traditional data repositories.

In the traditional context of a business or system use case this could be decomposed into a number of these more detailed and precise types of use case. What it does do however is provide a basic scope for such a further, more detailed, analysis to be performed.

What Does IBM’s PureSystem Announcement Mean for Architects?

Peter Cripps architecture , , ,

On April 11th IBM announced what it is referring to as a new category of systems, expert integrated systems. As befits a company like IBM when it makes an announcement such as this, a fair deluge of information has been made available, including this expert integrated systems blog as well as an expert integrated system home at ibm.com.IBM says expert integrated systems are different because of three things: built-in expertise, integration by design and a simplified experience. In other words they are more than just a static stack of software and hardware components – a server here, some database software there, serving a fixed application at the top. Instead, these systems have three unique attributes:

  • Built-in expertise. Expert integrated systems represent the collective knowledge of thousands of deployments, established best practices, innovative thinking, IT industry leadership, and the distilled expertise of solution providers. Captured into the system in a deployable form from the base system infrastructure through the application.
  • Integrated by design.  All the hardware and software components are integrated and tuned in the lab and packaged in the factory into a single ready-to-go system. All of the integration is done for you, by experts.
  • Simplified experience. Expert integrated systems are designed to make every part of the IT lifecycle easier, from the moment you start designing what you need to the time you purchase, set up, operate, maintain and upgrade the system. Expert integrated systems provide a single point of management as well as integrated monitoring and maintenance.

At launch IBM has announced two models, PureFlex System and PureApplication System. IBM PureFlex System provides a factory integrated and optimized system infrastructure with integrated systems management whilst IBM PureApplication System provides an integrated and optimized application aware platform which captures patterns of expertise as well as providing simplified management via a single management console.

For a good, detailed and independent description of the PureSystem announcement see Timothy Prickett Morgan’s article in The Register. Another interesting view, from James Governer on RedMonk, is that PureSystems are IBM’s “iPad moment“. Governer argues that just as the iPad has driven a fundamental break with the past (tablets rather than laptops or even desktops), IBM wants to do the same thing in the data center. Another similarity with the iPad is IBM’s push to have application partners running on the new boxes at launch. The PureSystems site includes a catalog of third party apps customers can buy pre-installed.

What I’m interested in here is not so much what expert integrated systems are but what exactly the implications are for architects, specifically software architects. As Daniel Pink says in his book A Whole New Mind:

..any job that depends on routines – that can be reduced to a set of rules, or broken down into a set of repeatable steps – is at risk.

So are expert integrated systems, with built-in expertise and that are integrated by design, about to put the job of the software architect at risk?

In many ways the advent of the expert integrated system is really another step on the path of increasing levels of abstraction in computing that was started when the first assembler languages did away with the need for writing complex and error-prone machine language instructions in the 1950’s. Since then the whole history of computing has really been about adding additional layers of abstraction on top of the raw processors of the computers themselves. Each layer has allowed the programmers of such systems to worry less about how to control the computer and more on the actual problems to be solved. As we move toward trying to solve increasingly complex business problems the focus has to be more on business than IT. Expert integrated systems therefore have the potential (and it’s early days yet) to let the software architect focus on understanding how application software components can be combined in new and interesting ways (the true purpose of a software architect in my view) to solve complex and wicked problems rather than focusing too much on the complexities of what middleware components work with what and how all of these work with different operating systems and computer platforms.

So, rather than being the end of the era of the software architect I see expert integrated systems as being the start of a new era, even an age of enlightenment, when we can focus on the really interesting problems rather than the tedious ones bought about by the technology we have inherited over the last six decades or so.

Choosing What to Leave Out

Peter Cripps architecture, creativity ,

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.

Why We Need STEM++ Graduates

Peter Cripps creativity, education , , ,

The need for more STEM (that’s Science, Technology, Engineering and Maths) skills seems to be on the agenda more and more these days. There is a strong feeling that the so called developed nations have depended too much on financial and other services to grow their economies and as a result “lost” their ability to design, develop and manufacture goods, largely because we are not producing enough STEM graduates to do this.Whilst I would see software as falling fairly and squarely into the STEM skillset (even if it is also used to  underpin nearly all of the modern financial services industry) as this blog post by Jessica Benjamin from IBM points out STEM skills alone won’t solve the really hard problems that are out there. With respect to the particular problems around big data Jessica succinctly says:

All the skills it takes to tell a good story, to compose a complete orchestra, are the skills it takes to put the pieces of this big data world together. If data is just data until its information, what’s a lot of information without the thought and skill of pulling all the chords together?

The need for right as well as left brained thinkers for solving the worlds really, really hard business problems is something that has been recognised for some time now by several prominent business leaders. Indeed the intersection of technology (left-brained) and design (right-brained) has certainly played a part in a lot of what technology companies like IBM and Apple have been a part of and made them successful.

So we need not just STEM skills but STEM++ skills where the addition of  “righty” skills like arts, humanities and design help us build not just a smarter world but one that is better to live in. For more on this check out my other (joint) blog The Versatilist Way.

Architecture Work Products as Social Objects

Peter Cripps architecture , ,

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:

  1. Conversational: people want to talk and have conversations with other people connected with the social object.
  2. 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.
  3. 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.

  1. Use what requirements you have and create a System Context identifying key actors (especially other systems).
  2. Try to break down what requirements into functional areas, ‘Customer Management’, ‘Facilities Management’, ‘Diary and Calendar Management’ etc.
  3. Draw an Architecture Overview showing the functional areas from 2) as subsystems/large-grain components.
  4. 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.
  5. Capture Architecture Decisions as to why you chose which components you did.
  6. 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.
  7. 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)

Peter Cripps architecture, creativity , ,

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.