Wednesday, December 22, 2010

On Being a Software Architect

Thanks to a wonderful bits of "webendipity" (something unexpected and useful found from surfing the web, a conjunction of web-serendipity) in this case a blog causing me to follow that blogger on twitter whose tweet pointed me to another blog, I came across An Overly Long Guide to Being a Software Architect by David Ing today which nicely parallels my previous effort on how not to be a (Software) Architect.

I particularly like Ing's number 11:

Finally my last tip is to never take advice from Top 11 tip lists. In nearly all cases there was only about 3 good points and with about 8 padding.

Definitely a lesson for me there I think. Maybe my New Years resolution should be to publish fewer lists!

Tuesday, December 21, 2010

You Can No Longer Call Yourself an Architect When...

Ten behaviours that might mean you can no longer call yourself an Architect...
  1. The majority of your output is created using Microsoft's Office suite.
  2. Your days are spent fighting the system rather than creating a system.
  3. You're fitting business to technology rather than the other way around.
  4. You think reuse is what you do with your shirt when you unexpectedly have to spend one extra day with the client (possibly wasting your time doing 2 above).
  5. The only stakeholders you deal with are your non-vegetarian colleagues during your evening meals at the Angus Steakhouse.
  6. You can no longer remember the difference between a For loop and a While loop.
  7. You think a view is something you don't normally get from your room in the tourist class hotels your company puts you up in.
  8. Your definition of a non-functional requirement is a functional requirement that isn't.
  9. You spend more time in the box than out of it.
  10. Add your favourite reason below.
This is probably my last post of the year and most certainly the last one before Christmas. Merry Christmas to everyone out there and, as it used to say on the front of The Beano at this time of year:

Happy New Year to All My Readers!

    Friday, December 17, 2010

    More Presentation Tips from the Frontline

    Here are some more tips based on some experiences gained this year from giving (lots of) presentations. I've also included a few good suggestions that have been suggested by friends and colleagues (they know who they are and I am happy to acknowledge them by name if they don't mind being publicised here).
    1. Don't give people negative information about you or your material. They will only use this against you in feedback. If you're not happy with the material you are delivering or its content you really should not be presenting it however at times we all have to deliver a presentation with dodgy slides or containing messages we may not agree with or fully understand. Try and spend time up front pulling out the key messages and deliver those rather than try to justify or apologise for poor slideware. Spending time practising is key.
    2. Check out the room you will be presenting in ahead of time and if it is big or has poor acoustics which will make it difficult to project your voice make sure you get a microphone (or be prepared to shout all through the presentation).
    3. Be aware of an audiences mood. Glazed eyes, playing with smartphones and doodling means you have lost them. Re-engage by throwing a question or two at the audience but better still follow 4 below.
    4. In the excellent book Brain Rules its author, John Medina, says that audiences tend to "check out" after 10 minutes and it is therefore important to pepper your presentation with attention grabbing events. These can be anecdotes, personal stories, jokes (if they are relevant to the presentation) or maybe playing a short video. Medina even recommends designing your presentation in 10 minute chunks where the end of each 10 minutes has one of these attention grabbing events.
    5. Buy yourself a good quality wireless presenter (AKA a 'clicker'). It gives you freedom to move around and blank the screen to avoid distractions during discussions. I have one of these which has served me well (always carry spare batteries though). Having a clicker more easily allows you to do number 6 as well.
    6. Don't stand still and just talk at the audience. If you, can walk around and engage with people (use eye contact when speaking). If you have any influence over the layout of the room make sure tables and chairs are laid out in such a way you can move in between them. Even if you are on a stage you can still move around (watch any Steve Jobs presentation to see what he does). Also use your pitch and volume to emphasis the key points of the presentation.
    7. Don't be afraid to say you don't know when asked a question. Unless you are an extremely good bluffer you will be rumbled and lose all crediability. Better is to admit you don't know the answer and offer to follow up afterwards (which you should do if you say you will of course).
    See also here for tips on creating technical presentations and here for what not to say when presenting.

    Tuesday, December 7, 2010

    Interprise Architecture and Ultra-Large-Scale Systems

    In a previous post I introduced the term “Interprise Architecture” to describe how the internet is breaking down the traditional boundaries of the enterprise and thus requires a new approach to Enterprise Architecture that's not just about describing what's inside the enterprise but also what's on the outside. No longer can Enterprise Architects create blueprints for some future state that the enterprise will one day reach with roadmaps for how that state will be achieved. There are too many disruptive influences and new technologies that are impinging on the enterprise that will not only mean the roadmap is sending you in the wrong direction but that you are probably using the wrong mode of transport to get there as well.
    I received a few comments on this from folk at the Software Engineering Institute (SEI)as well as Gartner. The work on Ultra-Large-Scale (ULS) Systems from the SEI particularly drew my attention and resonates nicely with some of my own thoughts. Here are some of the key ideas from the SEI report Ultra-Large-Scale Systems - The Software Challenge of the Future plus some additional musings of my own on what constitutes Interprise Architecture. First, ULS:
    • The SEI report on ULS systems was funded by the United States Department of Defence (DoD) which asked the SEI to consider future systems that could not only contain of billions of lines of code but also exhibit some, possibly all, of the following characteristics: decentralisation; conflicting, unknowable, and diverse requirements; continuous evolution and deployment; heterogeneous and changing elements; erosion of the people/system boundary; and normal failures of parts of the system.
    • ULS systems are likely to mean that traditional software and systems engineering approaches will no longer be adequate or can be the primary means by which such systems are designed (architected) or built.
    • ULS systems can be compared with cities whereas traditional systems can be compared with buildings. Buildings can be designed and built to a blueprint whereas cities emerge and are continuously adapting over time.
    • ULS systems are comprised of a dynamic community of interdependent and competing organisms (in this case, people, computing devices, and organizations) in a complex and changing environment. These are referred to as socio-technical ecosystems.
    • ULS systems are ones that are continuously evolving with new behaviour constantly emerging. In this respect they have the attributes of wicked problems where the problem is never definitively solved (or indeed understood).
    • ULS systems expect failure to be the norm and that unusual situations and boundary conditions will occur often enough that something will always be failing.
    The SEI report is primarily aimed at allowing the US military to develop new systems however I believe the key ideas that challenge the development of such systems also have wide applicability in business systems, the sort I'm most interested in. I see that what I have characterised as Interprise Architecture could therefore be applied to developing ULS business systems. Here are three examples of ULS business systems that might benefit from an Interprise Architecture approach:
    • Electronic Trading Systems. These are systems that trade securities (such as stocks, and bonds), foreign currency, and exchange traded derivatives electronically. They use IT to bring together buyers and sellers through electronic media and create a virtual market place. Such systems are typically built using proprietary software that has grown and evolved over many years. Investment banks have extremely complex technology requirements, as they have to interface with multiple exchanges, brokers and multi-dealer platforms, as well as their own pricing, profit and loss (P&L), trade processing and position-keeping systems. The challenge here then is not only the large numbers of systems but also the increasing complicated regulatory environment.
    • Electricity Generation and Metering. The generation and consumption of electricity faces a number of unique challenges including improved and more efficient use of green technologies as well as smart metering. Traditional electrical meters only measure total consumption and as such, provide no information of when the energy was consumed. Smart meters provide an economical way of measuring this information, allowing price setting agencies to introduce different prices for consumption based on the time of day and the season. 
    • Retail Systems. As retailers look for ever more cunning ways to get consumers to part with their hard-earned cash, traditional (i.e. high street) and electronic retail will merge more and more. For example not only can I use my 3G enabled smart-phone from the store I happen to be in to quickly compare prices in other stores in the area, the store itself can potentially detect I am shopping there using location based services and make me an enticing offer to shop there.
    So here are the seven challenges that I see Interprise Architecture must deal with in developing a ULS business system:
    1. Requirements are unknowable. Sometimes the very act of capturing a requirement (in whatever form) changes the nature of that requirement. Interprise Architecture must not only allow for continuously changing requirements but must also recognise that some uses of the system cannot be known up-front; hence the need to build more adaptable systems.
    2. The boundary between people and systems is at best blurred and at worst never established. Sometimes people will be users of the system, sometimes they (or at least the devices they own) will be part of the system.
    3. Development never stops but is a continuous cycle. Development processes as well as the projects that deliver such systems must therefore support this never-ending cycle.
    4. Systems continuously adapt and exhibit emergent behaviour. As new uses of the system are “discovered' by users the components that make up the system need to be able to adapt to satisfy those new behaviours.
    5. Failure (of parts of the system) is inevitable. Just like a fire in a building in a city can be localised and extinguished without by and large affecting the whole of a city then so to must Interprise Architecture allow for partial failure and reconfiguration of some components.
    6. Development tools and languages need to take account of the unpredictable and maybe even unspecifiable aspects of systems development. Traditional development tools favour left-brain thinkers where logic and reasoning can be applied to develop systems that move from abstract ideas to physical implementations (from models to code if you like). New tools for developing and describing Interprise Architectures need to be able to inject a bit of right-brain thinking by allowing creative multi-disciplinary elements to be added.
    7. Governance needs to be de-centralised. Strong, top-down governance (the sort favoured by Enterprise Architects) cannot work in a system where all the parts may not even be known. Interprise Architecture needs to recognise that some components are outside its control or immediate sphere of influence and have policies in place that allow new components to be added which don't harm or damage the whole system.
    As an interesting post-script to this the Financial Times recently published an article on Facebook and the plans that CEO Mark Zuckerberg has for advancing his brainchild. Zuckerberg had just announced a new feature on Facebook called Deals which allows smartphone users who have downloaded the Facebook application to check in at a physical location such as a coffee shop and get a reward. Zuckerberg says:

    If you look five years out, every industry is going to be rethought in a social way. You can remake whole industries. That’s the big thing.

    Facebook is one example of how external applications that allow users to impinge on the enterprise are changing how Enterprise Architects must think.

    Next, a story for what a ULS business system might look like and how it might work.

    Saturday, December 4, 2010

    A Tale of Two Cities

    I've recently been travelling in Asia working for a client delivering architectural training and was struck by the amazing contrast between the last two cities I visited, Singapore and Bangalore (or Bengaluru as it is now known). The contrast between these two cities set me thinking about Enterprise Architecture and how the approach to city planning can make or break how a city functions. For those not familiar with these two cities here are my fleeting observations (based on a few days spent in each).

    Singapore is a city state with a population of 5 million people. The predominant industries are shipping, financial services, manufacturing and tourism. Singapore's airport (Changi) is a modern airport which is the international hub for Singapore Airlines with good connections via the metro (known as MRT) to the city. The airport offers free wi-fi in all areas (I have a theory that the amount of free wi-fi you can get in a city is an indicator of the economic vitality of a place). Architecturally the city is a mix of old colonial style buildings (Raffles Hotel) and ultra-modern new buildings (the Marina Bay Sands hotel for example). Walking around the city you are struck how there is no graffiti, virtually no litter and no begging as well as by the large number of malls with designer shopping on offer and the usual Western outlets (Starbucks, Marks and Spencers, DKNY etc). There is very little serious crime (there being the mandatory death penalty for murder, rape and dealing in drugs). Whilst there is a lot of traffic the roads are well laid out with no significant traffic delays (at least whilst I was there). See here for another view of this city/state.

    By contrast Bengaluru is the third most populous city in India with an estimated population of 8 milllion and has seen rapid growth over the last 10 years due to it being the centre for outsourcing (especially IT with nearly all the large IT companies like Infosys, WiPro, HP and IBM having large development centres there). There is an international airport but with no good quality connections to the city. Virtually all visitors are business travellers with very little tourism. There is 15 minutes free wi-fi available in the business lounge only and even then only once you have surrendered your email and mobile phone number. A rapid transport system is being built (which was meant to be operational this month). Architecturally there are some modern buildings (mainly in the technology parks) together with large numbers of shanty towns and hastily constructed, low-cost apartments. Walking around the city you are struck by the vast amount of rubbish with dogs and cows wondering around. Despite it being a “high-tech” city there is still very obvious poverty with begging and homeless people sleeping on benches and in doorways. There are very few Western style shops  and virtually no designer outlets.

    So what Enterprise Architecture conclusions are to be drawn by comparing these two cities given we often compare Enterprise Architects with city planners and Solution Architects with building architects?
    • Enterprise Architects have a clear vision (captured as blueprints) of what IT systems the enterprise has and how they need to evolve to support the business strategy, maybe over a one, three and five year outlook. Walking around Singapore (and talking to people that live there) you get the impression there is a “master plan” being enacted. To some extent Singapore only exists because of the efficiency of its infrastructure and the quality of living it can provide to its citizens. This naturally pulls in people and businesses that can take advantage of that infrastructure.
    • Enterprise Architects define roadmaps showing how the enterprise will get from where it is today to where it needs to be (recognising that changes will be happening all the time). Singapore has clear plans for how the state will grow over the coming years. For example there are plans in place for various extensions of the MRT, some of which are currently under construction. It is expected that by the network will have of 540 km of track by 2050 which will be more than London's 408 km tube system.
    • Enterprise Architects need to be aware of both what functionality is required but also what qualities and constraints these functions will be delivered to.
      Enterprise Architects define clear principles that should be followed by Solution Architects architecting the individual buildings. Whilst there are several old colonial buildings as well as regional styles (China Town has some of the best Chinese architecture I have seen) Singapore has some of the most cutting edge modern architecture around. Despite this there is a strong sense of “harmony” amongst the styles and the feeling there are underlying principles that are in place to help achieve this harmony. 
    • Enterprise Architects enforce strong governance to enforce the blueprints, roadmaps and principles and ensure they are being followed. Singapore has strong (and severe) governance that enforces its laws. There have been very few recorded murder cases over the last decade and those there have been have nearly always ended in the guilty person being executed.
    Both cities are great places to visit, I'm sure Bengaluru will get to where Singapore is eventually, after all India is experiencing 8% growth which economists reckon will continue for some years to come. The Indian people have a tremendous attitude to work, what is needed is the good and honest governance of their leaders to turn cities like Bengaluru into a true, modern 21st century city.