pureapplication system

Steal Like an Artist

Peter Cripps creativity , , , , ,

David Bowie is having something of a resurgence this year. Not only has he released a critically acclaimed new album, The Next Day, there is also an exhibition of the artefacts from his long career at the Victoria & Albert museum in London. These includes handwritten lyrics, original costumes, fashion, photography, film, music videos, set designs and Bowie’s own instruments.

David Bowie was a collector. Not only did he collect, he also stole. As he said in a Playboy interview back in 1976:

The only art I’ll ever study is stuff that I can steal from.

He even steals from himself, check out the cover of his new album to see what I mean.

Austin Kleon has written a whole book on this topic, Steal Like an Artist, in which he makes the case that nothing is original and that nine out of ten times when someone says that something is new, it’s just that they don’t know the the original sources involved. Kleon goes on to say:

What a good artist understands is that nothing comes from nowhere. All creative work builds on what came before. Nothing is completely original.

So what on earth has this got to do with software architecture?

Eighteen years ago one of the all time great IT books was published. Design Patterns – Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides introduced the idea of patterns, originally a construct used by the building architect Christopher Alexander,  to the IT world at large. As the authors say in the introduction to their book:

One thing expert designers know not to do is solve every problem from first principles. Rather, they reuse solutions that have worked for them in the past. When they find a good solution, they use it again and again. Such experience is part of what makes them experts.

So expert designers ‘steal’ work they have already used before. The idea of the Design Patterns book was to publish patterns that others had found to work for them so they could be reused (or stolen). The patterns in Design Patterns were small design elements that could be used when building object-oriented software. Although they included code samples, they were not directly reusable without adaptation, not to mention coding, in a chosen programming language.

Fast forward eighteen years and the concept of patterns is alive and well but has reached a new level of abstraction and therefore reuse. Expert Integrated Systems like IBM’s PureApplication SystemTM use patterns to provide fast, high-quality deployments of sophisticated environments that enable enterprises to get new business applications up and running as quickly as possible. Whereas the design patterns from the book by Gamma et al were design elements that could be used to craft complete programs the PureApplication System patterns are collections of virtual images that form a a complete system. For example, the Business Process Management (BPM) pattern includes an HTTP server, a clustered pair of BPM servers, a cluster administration server, and a database server. When an administrator deploys this pattern, all the inter-connected parts are created and ready to run together. Time to deploy such systems is reduced from days or even, in some cases, weeks to just hours.

Some may say that the creation and proliferation of such patterns is another insidious step to the deskilling of our profession. If all it takes to deploy a complex BPM system is just a few mouse clicks then where does that leave those who once had to design such systems from scratch?

Going back to our art stealing analogy, a good artist does not just steal the work of others and pass it off as their own (at least most of them don’t) rather, they use the ideas contained in that work and build on them to create something new and unique (or at least different). Rather than having to create new stuff from scratch they adopt the ideas that others have come up with then adapt them to make their own creations. These creations themselves can then be used by others and further adapted thus the whole thing becomes a sort of virtuous circle:Adopt Adapt

A good architect, just like a good artist, should not fear patterns but should embrace them and know that they free him up to focus on creating something that is new and of real (business) value. Building on the good work that others have done before us is something we should all be encouraged to do more of. As Salvador Dalis said:

Those who do not want to imitate anything, produce nothing.

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.

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.