Thursday, March 29, 2012

Why we need STEM++ graduates

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.

Friday, March 23, 2012

Architecture work products as social objects

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.

Tuesday, March 20, 2012

Giving users what they want (maybe)

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.  

Tuesday, March 13, 2012

Making smart architecture decisions

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.