architecture

Learning Architecture (Or Anything Really)

Peter Cripps architecture , ,

I spent most of 2010 travelling the world teaching Architectural Thinking for a client. (Here is a reasonable description of some of what this covers. It’s the best publicly available description I can find but please contact me if you would like more information on this class).I always reckon that you learn just as much as a teacher as you do as a student (or should do) so here’s some stuff I learnt myself. This is not rocket science and many people may consider this obvious but for those for whom this is not the case I hope you find it useful.

  1. People learn best when they have some fun. This doesn’t mean you have to be a great comedian to deliver an effective training class however it does help if you can arrange some fun activities as part of the learning. Quizzes (that also inject an element of competition) work well as a way of re-enforcing peoples learning.
  2. Ensure that at least half the time (and preferably two thirds of it) are spent on getting the attendees to do something. This does not have to be a full-blown case study (though you certainly need one of those) but should at least include plentiful opportunities for discussions and Q&A sessions (where the questions are not just asked by the students).
  3. Less really is more. When delivering a lecture, or a complete class, especially one you are very familiar with. It is tempting to cram more and more information in as you deliver more classes. People ask a question, you answer it and think “hey, why don’t I create a slide for that for next time”. Don’t. Slide-creep is one of the great evils of our time. Rather thank thinking “what can I add” think “what can I remove”. Hand out detail as additional reading. Keep the main-deal brief.
  4. Try, whenever you can, to tell stories rather than deliver dry facts. For me a teacher is, above all else, an experienced practitioner. Introducing your own “war stories” at appropriate points is what makes a great and teacher.
  5. Great public speakers (Richard Feynman, Steve Jobs, Banjamin Zander) inject passion into what they have to say. If you are not passionate about what you are saying then maybe you should not be standing up in front of others saying it! Think about what first made you interested in the topic you are delivering and weave that into the storyline. Injecting some of your personal self into a subject helps engage the audience and make them believe in what you have to say.

Finally take a look at this great advice from Seth Godin on organising a retreat. It may not be a full blown retreat you are organising but it contains great advice for just about any learning event where you want to get the best out of people.

2011 Architecture Survival Guide

Peter Cripps architecture ,

An article in last Sundays Observer newspaper about Facebook has set me thinking about how we architects can not only survive in today’s rapidly changing technological environment but also actually make a positive difference to the world (even if it’s not on the scale of Facebook, assuming you think that has made a positive impact on the world).The article by John Naughton examines the claim by the Winklevoss twins that they were ripped off when they reached a settlement with Mark Zuckerburg in 2008 after they claimed it was they who had invented Facebook. Their claim is that the number of Facebook shares they acquired was based on a false valuation. For an entertaining view of this see, or rent, The Social Network which goes into the history of how Facebook came into being. The article goes on to pose the question: would we now be looking at a social networking service with 600 million users if the Winklevoss twins had been the ones to develop Facebook?

Naughton thinks not and goes on to explain that although the Winklevoss twins were not stupid they probably “laboured under two crippling disadvantages”:

  1. They were, and probably still are, conventional people who may have been good at “creating businesses in established sectors but who find it hard to operate in arenas where there are no rules”.
  2. The twins weren’t techies and so had no real insight into the technology they were creating and its possibilities. They were therefore less likely to “spot the importance of allowing Facebook to become a software platform on which other people could run applications”.

Here’s my takeaway from this if you want to come up with new ideas, at whatever scale, no one else has thought of.

  1. Don’t think conventionally. Conventional thinking will end up creating conventional business models. Conventional means doing what you’ve been told or what your peers do. Someone once said “fear of our peers makes us conservative in our thinking“. Zuckerburg was not only fearless of his peers (the Winklevoss twins) but had no qualms about using (some would say stealing) their ideas and using them for his own ends. I guess it poses an interesting moral dilemma about when it is right to steal someone elses idea because you think you can do more with it. Facebook paid for this by handing over cash and shares to the Winklevoss twins but have benefited from this ‘investment’ many times over.
  2. Don’t think like everyone else. Walter Lippmann (a writer and political commentator) once said “where we all think alike, no one thinks very much.” Some people claim that Zuckeburg (if you believe the movie at any rate) exhibits characteristics that place him on the autistic spectrum. (actually as having Asperger syndrome). One of the characteristics of someone with Aspergers is that they display behavior, interests, and activities that are restricted and repetitive and are sometimes abnormally intense or focused. Zuckeburg not only thought differently to everyone else but took an idea and focused on it intensely (many, many hours of programming) until Facebook was created.
  3. Think visually. Interesting related to number 2. People on the autistic spectrum are often more visual thinkers than those who are not. We often joke about “back of an envelope” or “back of a fag packet” designs but setting aside the medium the ability to visualise your thoughts quickly and succinctly is a key characteristic it’s worth fostering. One of my more memorable ad-hoc design sessions took place over a meal in a restaurant where we used the table cloth as a our drawing canvas. Luckily it was a paper table cloth!
  4. Don’t get out of touch with technology. One of the dangers of becoming an architect in order to make yourself “more valuable” (see Dilbert below) is you not only lose touch with technology but you lose the ability to exploit it in ways others may not see. Making Facebook an open platform has been one of the key factors in its runaway success. I’ve discussed before the importance of being a versatilist (broad in several disciplines and deep in a few specialisms) and this ones all about picking your technology (we can’t all be good at everything) and specialising yourself in it!

Dilbert.com

Architecture is Architecture?

Peter Cripps architecture ,

At OT 99 (that’s Object Technology 1999, now known as SPA for Software Process Advancement) I attended a session by Kent Beck called Software is Software – Beyond the Horseless Carriage. The basic premise of Kent’s talk was that it was about time the software business “grew up” and its practitioners recognise it for what it is, a discipline in its own right which no longer needs to continuously borrow terms and techniques from other industries and disciplines. The title of the session refers to the time when the automobile was first invented and people called them horseless carriages because horse-drawn carriages were the only frame of reference they had. Unfortunately, 12 years later, I don’t think we have quite got around to jettisoning our horseless carriages, especially in the upfront work that is done in trying to map out the major system components and their relationships, sometime referred to as architecture (a word which itself is borrowed from another profession of course). On the face of it this may not seem to be a problem; after all those other industries (civil engineering, auto-engineering even film making) have been around a lot longer and so must be able to offer good advice and guidance to the business of software mustn’t they? Actually, I think there is a problem and Kent Beck was, and still is, right.

  • The business of ‘making’ software is fundamentally different from any other human endeavor. Software is infinitely malleable and potentially changeable right up to (and sometimes after) it has gone into production. No other engineering discipline has that flexibility. At some point drawings and blueprints have to be signed off, factories and production lines have to be built, building sites prepared and production begun. After this any change becomes prohibitively expensive. With software the perception (and sometimes the reality) is that code changes can be made right up to the moment the software ships.
  • Most other engineering disciplines have fairly well defined job roles, often with their own professional organisations, training programmes and qualifications and well understood and mature tools. These roles are usually carried out by separate individuals (in the construction industry it’s unlikely the architect will roll her sleeves up and start laying bricks).
  • The engineering and manufacturing approach, or process, is by and large pretty well understood and has been refined over a long period of time (sometimes hundreds of years). The approaches can be taught and are an integral part of the role of being an architect or aero-engineer. Further, these approaches are built around a common language which is also taught and well understood by its practitioners.

A rigorous approach to the field of software architecture needs to recognise the differences whilst at the same time understanding its constraints and build a solid, engineering based approach to its development. This should include killing off the endless debates of agile versus waterfall or structured versus object-oriented and any of the other interminable ‘religious wars’ that we seem to love embarking on and focus in on what matters: applying IT in a reasoned and structured way to solving real-world (and sometimes complex) business problems.

As we enter the new year lets celebrate the field of software development for what it is and help forge the right amount of rigor and discipline in creating a ‘proper’ profession that finally loses the shackles of all those other industries. After all as this guy says (far more eloquently than me) “the processor is an expression of human potential” and is “akin to a painter’s blank canvas” (see this great drawing). I’d like to think of us architects as the painters ready to fill that canvas with great art. Oh heck, but that means we are now comparing architecture with art and that would never do.

On Being a Software Architect

Peter Cripps architecture

Thanks to a wonderful bit 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!

You Can No Longer Call Yourself an Architect When…

Peter Cripps architecture ,

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!

Interprise Architecture and Ultra-Large-Scale Systems

Peter Cripps architecture , , ,

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.

A Tale of Two Cities

Peter Cripps architecture , ,

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.

Architecture Drill Down in the UML

Peter Cripps architecture , , , ,

Solution Architects need to create models of the systems they are building for a number of reasons:

  • Models help to visualise the component parts, their relationships and how they will interact.
  • Models help stakeholders understand how the system will work.
  • Models, defined at the right level of detail, enable the implementers of the system to build the component parts in relative isolation provided the interfaces between the parts are well defined.

These models need to show different amounts of detail depending on who is looking at them and what sort of information you expect to get from them. Grady Booch says that “a good model excludes those elements that are not relevant to the given level of abstraction”. Every system can be described using different views and different models. Each model should be “a semantically closed abstraction of the system” (that is complete at what ever level it is drawn). Ideally models will be both structural, emphasizing the organization of the system, as well as behavioral, emphasizing the dynamics aspects of the system.

To support different views and allow models to be created at different levels of abstraction I use a number of different diagrams, created using the Unified Modeling Language (UML) in an appropriate modeling tool (e.g. Rational Software Architect or Sparx Enterprise Architect). Using a process of “architecture drill-down” I can get both high level views as well as detailed views that are relevant to the level of abstraction I want to see. Here are the views and UML diagrams I create.

  • Enterprise View (created with a UML Package diagram). This sets the context of the whole enterprise and shows actors (users and other external systems) who interact with the enterprise.
  • System View (Package diagram). This shows the context of an individual system within the enterprise and shows internal workers and other internal systems.
  • Subsystem View (Package diagram). This shows the breakdown of one of the internal systems into subsystems and the dependencies between them.
  • Component View (Component diagrams and Sequence diagrams). This shows the relationships between components within the subsystems, both static dependency type relationships (through the UML Component diagram) as well as interactions between components (through the UML Sequence diagram).
  • Component Composition View (Composite Structure diagram). This shows the internal structure of a component and the interfaces it provides.

Note hat a good tool will link all these together and ideally allow them to be published as HTML allowing people without the tool to use them and also navigate through the different levels. Illustrative examples of the first three of the diagrams mentioned above are shown below. These give increasing levels of detail for a hypothetical hotel system. Click on the picture to get a bigger view.

Enterprise View
System View
Subsystem View

In the actual tool, Sparx Enterprise Architect in this case, each of these diagrams is linked so when I click on the package of the first it opens up the second and son on. When published as HTML this “drill-down” gets maintained as hyperlinks allowing for easy navigation and review of the architecture.

Hire an Architect

Peter Cripps architecture ,

Seth Godin has a great definition of what an architect is in his blog here. Here’s the description:

Architects don’t manufacture nails, assemble windows or chop down trees. Instead, they take existing components and assemble them in interesting and important ways.

He goes on to say that:

…intentionally building a structure and a strategy and a position, not focusing your energy on the mechanics, because mechanics alone are insufficient. Just as you can’t build a class A office building with nothing but a skilled carpenter, you can’t build a business for the ages that merely puts widgets into boxes.

I like this because for me this is absolutely the essence of what an architect does, take existing components and put them together in new and interesting ways. That’s exactly what Tim Berners-Lee did when he created the web. The key skill is not to get bogged down in the detail but to maintain the big picture of whatever it is you are doing. It applies equally to IT systems just as much as it does to buildings.

Versatilism and Wicked Problems

Peter Cripps architecture, creativity ,

The world is full of wicked problems. As stated previously a wicked problem is one that is:

  • Unique
  • Difficult to define
  • Linked to other problems
  • Not always clear when its been solved

Some wicked problems can benefit from the reasoned application of information technology to help in solving them. Solving wicked problems needs an innovative approach and the use of design thinking. A versatilist is someone who knows how to apply design thinking and can orchestrate the skills of multiple disciplines in solving wicked problems. A versatilist is also someone who:

  • Applies both left (logical) and right (artistic) brain thinking to the problem.
  • Uses rapid prototyping to test out solutions.
  • Understands that everything is connected to everything else and that sometimes solving one problem results in many more.
  • Is not afraid to disrupt the status quo and risk ridicule from his peers.
  • Is not afraid to propose a solution to a problem before the problem is completely understood.
  • Iterates (maybe many times) rather than expecting to arrive at a solution following a (simple-minded) analysis of the problem.

The world needs more versatilists if we are to solve the truly wicked problems. Solving wicked problems is one of the things we must do if we are to build a Smarter Planet.