Architecture and Experience

A project I’m working on now – helping the Portland Police Bureau design their next-generation collaboration system – got me thinking of how people get the process of software design wrong. Far too often, people start by trying to define the functionality of the software application. “We want it to do this. We want to do that.” And they end up with a long list of requirements that they send off to the coders to magically make whole. That’s a sure way to fail.

One thing I’ve learned working with software development is that software is 80% architecture and 20% coding. The real art is in the architecture. Once you’ve got that down, the coding is easy.

But architecture design is hard and complex. You need to do some deep thinking about how the pieces fit together. You also need to understand how it will allow for future development, for good software is a living organism that evolves, not a fixed product. That’s because we – the users – evolve, and so do our needs.

This architecture is also multi-dimensional. There are six key levels you need to consider:

• The experience
• The knowledge
• The information
• The software
• The system
• The components

Let’s go through them one at a time.

The top level of architecture is the experience architecture – the experience that the software creates for the user. The user enters into the experience with a problem or an aspiration. How is this experience going to help them address that problem or aspiration quickly and elegantly? To evaluate the success of this experience, you need to appreciate that it’s both linear and intellectual as well as spacial and emotional.

The next level down is the knowledge architecture. Within every organization are centers of expertise and knowledge. For a police department, it might be the gang team – if you want know who has the pulse on the gang activities – or the district officers, if you want to know what chronic issues are troubling a neighborhood. If you understand where the knowledge is located in an organization, you can begin to knit it all together into a solution.

Below that is the information architecture. Now we’re beginning to get into the software realm. Information resides in different databases or on spreadsheets. Often it’s scattered around and difficult to access. And some of it can’t be accessed by a system at all, because it’s stored in a two-legged computing device called a human being. So it’s critical to understand how to collect and integrate organizational information.

Now and only now do we get down to the software architecture. Only when you understand the architectures above it can you design a software architecture that can support it. But the architecture design does not end there, for next comes the hardware elements of the solution, which need to support the software architecture. You start with the system architecture, then knit together the hardware devices (the computers, storage devices, etc.) and then the device and component architectures that allow the software to perform quickly and consistently.

Sound like a lot of work? It is. That is why it represents 80% of the effort.

But the key point here regarding the innovation process is that to be successful, you need to start with the experience. In the case of the police department, you begin with police officers who need to become as smart as they can in the three minutes they have before they arrive at the scene, while driving 60 miles an hour down city streets and punching a few key words into their onboard computers. How do you do that?

I would argue that companies who understand experience architecture deeply are more successful than ones who don’t – even if the latter make stuff with great functionality. There were mp3 players that did lots more than the iPod, and ones that still do. But clearly Apple started with the experience architecture. They didn’t ask, “What do we want this thing to do?” They asked, “What do we want the user to experience when they use it?”

Apple gets it, and they effectively control everything right down to the component architecture, which is why their user experiences are nonpareil. But how can you do this if you’re not Apple?

You can start by not doing things backwards. Too often creators start by outlining the functionality, and then deal with the user experience only as an afterthought. That’s exactly backwards. Because it’s not the software that creates value – it’s the experience.

But even IBM admits that they don’t have the internal resources to quickly design, build, and evolve fully integrated architectures. That’s why they’ve embraced the principles of open innovation, in which they work in agile partnerships with others to quickly develop new market solutions.