zen

Avoiding the Legacy of the Future

Peter Cripps architecture , , , , ,

Kerrie Holley is a software architect and IBM Fellow. The title of IBM Fellow is not won easily. They are a group that includes a Kyoto Prize winner and five Nobel Prize winners, they have fostered some of the IBM company’s most stunning technical breakthroughs―from the Fortran computing language to the systems that helped put the first man on the moon to the Scanning Tunneling Microscope, the first instrument to image atoms. These are people that are big thinkers and don’t shy away from tackling some of the worlds wicked problems.

Listening to Kerrie give an inspirational talk called New Era of Computing at an IBM event recently I was struck by a comment he made which is exactly the kind of hard question I would expect an IBM Fellow to make. It was:

The challenge we have is to avoid the legacy of the future. How do we avoid applications becoming an impediment to business change?

Estimates vary, but it is reckoned that most organizations spend between 70% and 80% on maintenance and only 30% to 20% on innovation. When 80% of a companies IT budget is being spent in just keeping the existing systems running then how are they to deploy new capabilities that keep them competitive? That, by any measure, is surely an “impediment to business change”. So, what to do? Here are a few things that might help avoid the legacy of the future and show how we as architects can play our part in addressing the challenge posed in Kerrie’s question.

  1. Avoid (or reduce) technical debt. Technical debt is what you get when you release not-quite-right code out into the world. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an error-prone deployment. Reducing the amount of technical debt clearly reduces the amount of money you have to spend on finding and patching buggy code. Included here is code that is “buggy” because it is not doing what was intended of it. The more you can do to ensure “right-first-time” deployments the lower your maintenance costs and the more of your budget you’ll have to spend on innovation rather than maintenance. Agile is one tried and tested approach to ensuring better, less buggy code that meets the original requirements but traditionally agile has only focused on a part of the software delivery lifecycle, the development part. DevOps uses the best of the agile approach but extends that into operations. DevOps works by engaging and aligning all participants in the software delivery lifecycle — business teams; architects, developers, and testers; and IT operations and production — around a single, shared goal: sustained innovation, fueled by continuous delivery and shaped by continuous feedback.
  2. Focus on your differentiators. It’s tempting for CIOs and CTOs to think all of the technology they use is somehow going to give them that competitive advantage and must therefore be bespoke or at least highly customised packages. This means more effort in supporting those systems once they are deployed. Better is to focus on those aspects of the business’ IT which truly give real business advantage and focus IT budget on those. For the rest use COTS packages or put as much as possible into the cloud and standardise as much as possible. One of the implications of standardisation is that your business needs to change to match the systems you use rather than the other way around. This can often be a hard pill for a business to swallow as they think their processes are unique. Rarely is this the case however so recognising this and adopting standard processes is a good way of freeing up IT time and budget to focus on stuff that really is novel.
  3. Adopt open standards and componentisation. Large monolithic packages which purport to do everything, with appropriate levels of customisation, are not only expensive to build in the first place are likely to be more expensive to run as they cannot easily be updated in a piecemeal fashion. If you want to upgrade the user interface or open up the package to different user channels it may be difficult if interfaces are not published or packages themselves do not have replaceable parts. Very often you may have to replace the whole package or wait for the vendor to come up with the updates. Building applications from a mix of COTS and bespoke components and services which talk through an open API allows more of a mix and match approach to procuring and operating business systems. It also makes it easier to retire services that are no longer required or used. The term API economy is usually used to refer to how a business can expose its business functions (as APIs) to external parties however there is no reason why an internal API economy should not exist. This allows for the ability to quickly subscribe to or unsubscribe to business functionality making business more agile by driving a healthy competition for business function.

Businesses will always need to devote some portion of their IT budget to “keeping the lights on” however there is no reason why, with the adoption of one of more of these practices, the split between maintenance and innovation budgets should not be a more 50:50 one than the current highly imbalanced 70:30 or worse!

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.

On Being an Effective Architect

Peter Cripps architecture ,

In a previous blog entry I talked about the key skills architects needed to develop to perform their craft which I termed the essence of being an architect. Developing this theme slightly I also think there is a process that architects need to follow if they are to be effective. Stripped down to its bare essentials this process is as shown below.

This is not meant to be a process in the strict SDLC sense of the word but more of a meta-process that applies across any SDLC. Here’s what each of the steps means and some of the artefacts that would typically be created in each step (shown in italics).

  • Envision – Above all else the architect needs to define and maintain the vision of what the system is to be. This can be in the form of one or more, free-format Architecture Overview diagrams and would certainly include having an overall System Context that defined the boundary around the system under development (SUD). The vision would also include capturing the key Architectural Decisions that have shaped the system to be the way it is and also refer to some of the key Architecture Principles that are being followed.
  • Realise -As well as having a vision of how the system will be the architect must know how to realise her vision otherwise the architecture will remain as mere paper or bits and bytes stored in a modeling tool. Realisation is about making choices of which technology will be used to implement the system. Choices considered may be captured as Architectural Decisions and issues or risks associated with making such decisions captured in a RAID Log (Risks-Assumptions-Issues-Dependencies). Technical Prototypes may also be built to prove some of the technologies being selected.
  • Influence -Above all else architects need to be able to exert the required influence to carry through their vision and the realisation of that vision. Some people would refer to this as governance however for me influence is a more subtle, background task that, if done well, is almost unnoticed but nonetheless has the desired effect. Influencing is about having and following a Stakeholder Management Plan and communicating your architecture frequently to your key stakeholders.

Each of these steps are performed many times, or even continuously, on a project. Influencing means listening as well and this may lead to changes in your vision thus starting the whole cycle again.

Adopting this approach is not guaranteed to give you perfect systems as their are lots of other factors, as well as people, that come into play during a typical project. What it will do is give you a framework that allows you to bring some level of rigor to the way you develop your architectures and work with stakeholders on a project.

Keeping Your Creative Mojo

Peter Cripps creativity ,

In this article Mary Beth Maziarz proposes nine ways to “screw up your creative mojo”. Sometimes, despite our best efforts, we inevitably find ourselves in a bit of a creative cul-de-sac that we feel unable to get out of. At times like this, or just as a way of approaching our work from a new angle, it helps to try and bring some creative, right-brained, thinking to problem solving. Here’s how Mary’s creativity tips might apply to the world of architecture.

  1. Collect the pieces when they come. Solutions to problems rarely arrive fully formed and on-demand. Sometimes solutions to problems arrive at inopportune times. We have enough digital devices at our disposal these days never to have the excuse of not capturing those thoughts as they occur whether it be in the middle of the night or when out walking the dog.
  2. Stop talking and do it. Architects, especially it seems, are very good at talking around all aspects of a problem endlessly. Sometimes you just have to get on and do it. If you are not sure about something use prototypes or proofs of concept to help crystallize your ideas.
  3. Decide the time is now. Architecture is all about compromise. The role of the architect is, as much as anything, about making decisions based on the best information available at the time. Don’t prevaricate endlessly until you have the perfect solution, you never will!
  4. Detach from critical thoughts and circles.You are your own worst critic, there are always many, many reasons for not doing something but usually only one for doing it. Do what you think is right and learn from your mistakes.
  5. Find and believe in your strengths. Not thinking you are clever enough, educated enough or simply having the right level of authority in your organisation can sometimes prevent you from coming out with that great idea.This is about believing in yourself.
  6. Focus your energies. This is about avoiding the distractions and trivia of everyday life (email, filling in that expense form, tweeting you’re in the coffee shop etc) that prevent us from doing our art. Read Steven Presfield’s War of Art (no, this is not written the wrong way round for all you business “warriors” who have read Sun Tzu’s book).
  7. Try anything. Architects tend to be more logical, left-brain thinkers. Reach out to your left-brain to unblock your thoughts and improve your creativity.
  8. Enjoy the journey and your companions. Getting there is part of the fun. Work with others to make the journey more pleasant. Learn from your colleagues (both junior and senior to you) and let them learn from you. Work together, not against each other and reject the cynics and the ne’er-do-well’s.
  9. Be nice to yourself. It’s increasingly difficult these days to justify that long lunchtime walk or afternoon away from the office as proper work. Enjoying yourself (as part of your work) helps those creative juices to flow though.

How to Create Effective Technical Presentations

Peter Cripps presenting , ,

One of my great bugbears in life is the dire nature of the average technical presentation produced by IT folk in general and architects in particular. I’m not saying all architects produce bad presentations or that architects are the only culprits. It’s just that I tend to see more presentations from this particular group so am more inclined to comment on them. The main problems I see are:

  • Too much text/information on a slide.
  • Text too small to read unless you are in the front row and have 20-20 vision.
  • Inconsistent use of colour.
  • Poor layout.
  • Use of dreadful and completely irrelevant clip-art.
  • Far too many slides given the length of the presentation.
  • Unnecessary and confusing animations.
  • I could go on…

Before I go any further I confess I have produced some pretty dreadful presentations in my time where I have fallen foul of most, if not all, of the above at some point. However I’ve recently been reading the books (Presentation Zen and Presentation Zen Design) and blog of Garr Reynolds and thinking how what he says can help with people who need to produce technical presentations. Here are five tips based on the advice from Garr’s books that will help you next time you have to create a technical presentation.

  1. Don’t put more than you need to in the presentation. The first, and I think best piece of advice, is to recognise the inherent limitations of presentations as a communication mechanism and try and mimimise the amount of information you present. Hopefully the audience is there to listen to what you have to say not to see how good you are at slideware. Presentations should summarise, mainly in pictures and in as few words as possible, what you have to say. If you do need to provide additional information then hand this out as a supplement at the end of the presentation. Never just hand out your slides, that’s just cheap and shows you don’t care! Anyway, a good presentation should, by definition, not stand alone. It should only work when the speaker is there to present it.
  2. Make use of all the space on a presentation slide. This means removing all the unnecessary garbage that can often be found on a presentation template. You know the sort of thing I mean, there is a header and footer showing various aspects of your companies logo that take up more room than the presentation content itself! The only place a company logo should appear is on the title page. After that you should have complete use of the limited space you have available to you. Whilst talking about space you should not feel you have to fill all of the space with content. Sometimes having empty space is just as important as the content as it can provide contrast and at the same time help direct the viewers eye to the positive elements.
  3. Use words rarely. This is the most difficult piece of advice to take. It is tempting to fill a slide up with words because you are worried you will forget some important piece of information so you have to write this on the slide. Unfortunately giving a good presentation does mean you should practice, practice and practice and memorise what you want to say as much as possible. If you are in a rush and don’t have time then use cue cards but don’t read the words on the slide. Where you do need to use words to summarise key points then I like to try and follow what I call the five by five rule. That’s five words in a line and a maximum of five lines (yes really). Finally text should be viewable from people in the back row. To check this put PowerPoint in slide sorter mode, make the slides 100% and make sure you can read the text without squinting at the screen. This is the view people in the back row will have. Actually, I lied, that wasn’t the final point on this. You should also use consistent and clear typography throughout. Don’t go overboard with lots of different fonts and font sizes.
  4. Use colour, layout and other design techniques for diagrams. Technical presentations by there very nature often include lots of diagrams. By necessity these will usually need to be simplified in order to get the key points across. Make use of colour to show contrast, lay things out in a consistent and meaningful way and follow some basic design techniques such as the rule of thirds to ensure your diagrams have maximum impact.
  5. Use pictures wherever possible. I’m a recent convert to this. I love the idea of using pictures to get across key ideas and concepts. As a keen photographer I try and use my own images wherever I can however where I need something that I don’t have to hand I use stock photos (yes, which I buy with my own money). Don’t be a cheapskate and download low-res images from the web. Spend a few £££’s or $$$’s and get good quality stock images from somewhere like istockphoto.

This is a very short introductory set of ideas for making effective technical presentations. Try some of them next time you have to do a presentation and see what comments you get.

Finally, if you want to view some good quality presentations take a look at the technical presentations at slideshare.net.

Architecture Refuseniks

Peter Cripps architecture ,

re-fuse-nik (noun) a person who refuses to cooperate with a system or comply with a law because of a moral conviction

Some IT architecture refusenik types who may or may not have moral convictions about this sort of thing:

  1. It’s all in the code – Just wants to get on with cranking out what really matters (to them) the code. Thinks that anything to do with architecture is poncey nonsense and that all architects need to “get real” and realise that code is king.
  2. It’s all in the process – Can create the worlds most complex process that will deliver, er well nothing actually because no one will ever take any notice of it and just get on with the real work anyway.
  3. It’s all in the clouds – Will pontificate endlessly on things like ‘governance’, ‘process’, ‘reviews’ but will never actually deliver anything.
  4. It’s all in the model – Opposite of the coder. Thinks the system is completely describable by models and says their work is done, and the system is ‘complete’ once 35 (or more) UML models have been created.
  5. It’s all in the plan – As long as we have a plan that is at least 8 levels deep and has every minute of every day accounted for it’ll all just work at the end of it.

Five Tips on How to Think Like a Designer

Peter Cripps comment , ,

I got this idea from Garr Reynolds blog entry 10 Tips on how to think like a designer. Ten is too large a number for my simple brain so instead I’ve picked the five that I think we as software architects can most learn from the world of design.

  1. Embrace constraints. An architect often complains about the constraints and limitations she has to work under (especially those related to money, time and resource). The skill is to accept constraints and figure out what you can do with the resources you have. After all, a completely unbounded problem with total freedom on how to solve it is likely to end up never being solved. Remember how the NASA engineers managed to fix the Apollo 13 CO2 filter problem using just what they knew was available on the spacecraft. Now that’s embracing constraints.
  2. Practice restraint. This is related to the previous one. As Reynolds says: “any fool can be complicated and add more, it takes discipline of mind and strength of will to make the hard choices about what to include and what to exclude”. As software architects we are often overwhelmed with choice when putting together a solution. There are often many different vendors software products and packages from which to choose and, of course software, by definition, is malleable and can be shaped in many different ways. The trick here then is to practice self-constraint and go for simplicity rather than complexity and cleanness of form rather than clutter and obfuscation.
  3. Check your ego at the door. Ultimately all software, no matter how deeply imbedded or how far it is along the food chain, has an end user to cope with. How that user interacts with and understands the system of which your software is a part depends on how well designed it is. The software architect usually has many different people to deal with (people who use the system directly, people who must maintain the system, people who need to ensure the system is secure, the list goes on). Each of these people has a “stake” in the system (hence the name we some refer to them by as “stakeholders”) and a good architect understands the needs of these stakeholders and is empathetic towards those needs. Empathy is a difficult soft-skill to master but is very important to acquire. It is so important that Dan Pink in his book A Whole New Mind states it as one of the key differentiators that will mark out those people who are able to survive the 21st century world of work where everything is outsourced, commoditised or performed more cheaply by a computer.
  4. Become a master storyteller. You may have just devised the greatest software architecture the world has ever seen but if you cannot sell that solution it’s not going to be any good to anyone and will most likely never see the light. Much software is, by its very nature, complex and describing what it does and what are its benefits can be difficult. Storytelling, that is weaving a story around your system by illustrating it verbally and using multi-media to back up what you are saying can help. Don’t rely on complex and overly-cluttered PowerPoint slides when trying to describe what the system does but instead relate it to everyday experiences your audience are likely to identify with.
  5. Obsess about ideas not tools. As Reynolds says: “tools are important and necessary, but they come and go as better tools come along”. Probably no discipline is more blessed (sic) with tools than ours is. Whilst tools are clearly important to the software architect remember they are a means to an end so don’t sweat over them too much. Instead concentrate on the ideas and use pencils and paper or whiteboards and pens to capture your ideas. These also have the benefits of being readily available and don’t suffer from expired batteries.

Software Architecture Zen?

Peter Cripps architecture ,

Okay so why software architecture zen? According to Wikipedia Zen “…de-emphasizes theoretical knowledge in favor of direct, experiential realization through meditation…”. So, my goal here is the practical application of software architecture, based on my own and others hard earned experiences in both doing and teaching out in the real-world. I got the idea from one of my favorite blogs, Presentation Zen. which is all about creating great presentations based on simplicity and “cleanliness” of design.

For a great exposition on Zen as applied to software architecture see this paper by Philippe Kruchten from 2001. My favorite bit is:

The architect doesn’t talk, she acts.
When this is done,
the team says, “Amazing:
we did it, all by ourselves!”