Mobile Transport Ticketing standards

Tickets please.
Photo: Rail Technology Magazine / Progressive Media Group

The pain you have to go through to travel abroad has always bugged me. I went on a Swiss walking holiday last year and had to buy our rail passes months in advance and there were so many options and routes from various airports that my wife and I burned many an hour discussing alternatives. How much easier would it be if there was an easy way to just buy a ticket from Ipswich to Wengen, Switzerland via any of those routes with your selected airline? Then choose the trains to fit your needs.

That was the dream of the OSPT Alliance and their ticketing interoperability initiatives. The UK transport industry, Department of Transport and the Association of Train Operating Companies (ATOC) instead went for the ITSO standard as national public transport Smart ticketing technology started to come into reality.

Now it appears the two organisations are beginning to work together to avoid the need for travellers to use two different formats and move towards common ticketing on Smart card and eventually Mobile phones, e.g. using NFC.

The International Transport Smartcard Organisation (ITSO) are a limited company who manage that standard from Milton Keynes. ITSO ticketing is one of four broad groups of fulfilment used by national rail. The others are paper tickets, primarily Credit Card Size Tickets (CCST), barcode (used for self printing) and Oyster which is the proprietary format card that has been so hugely successful in London. The ITSO members who supply ticketing and the terminals for validation at stations (so-called POSTs) and by handheld terminals on trains sign up to a code of practice for interoperability and security.

The OSPT Alliance defines the CIPURSE open standard, based on a number of contactless and Near Field Communications (NFC) specifications and it appears to be firmly aiming at the mobile App market. The V2 CIPURSE Mobile spec is published and available to members for evaluation.

We’re not sure exactly how closely these organisations will be working together. The press release today (reproduced below) mentions becoming members of each others’ committees and leveraging complementary aspects. It probably means there will be some kind of integration abstraction layer in the card or network back to the various back-end systems. It probably also means more complexity and work for apportionment and settlement systems run by people like our customer who spoke at the recent AWS Summit ”ATOC Rail Settlement Plan“. In some ways it makes apportionment easier as they should soon be able to track exactly where a customer using mobile ticketing travelled rather than apportion according to estimated volumes who take certain routes as they do today.

Whichever way you look at it, the future world of ticketing is likely to be mobile so what do rail customers think? The quote below comes from the excellent Passenger Focus report on ticketing – available on their website on the subject of buying tickets on their Mobile Phone.

Some respondents had experience of this being a helpful information source that was trusted to identify best tickets or fares for unfamiliar journeys, thereby allaying validity concerns. However all acknowledged that they were unlikely to buy tickets on the phone so these would still need to be purchased elsewhere, meaning that the choice/complexity paradox can only be partially overcome through this channel.

The full emailed press release from the OSPT Alliance is reproduced below:

The Open Standard for Public Transport™ (OSPT) Alliance and ITSO Ltd., the organization responsible for the UK national specification for smart ticketing, today announced they have agreed to participate as members in each other’s organizations and to explore ways they can work together to promote the use of open security standards in public transit for smart ticketing and electronic fare collection systems.

Through their shared commitment to the use of open standards, these two leading public transit standards bodies intend to leverage the complementary aspects of their standards and ecosystems and discuss how they could be combined to create solutions that would be mutually beneficial to their respective members.

“We are pleased to have ITSO join the OSPT Alliance as an associate member, and look forward to exploring how our shared vision for the future of open standards in public transit can result in a mutually beneficial relationship,” said Laurent Cremer, executive director for the OSPT Alliance. “ITSO is an established, recognized player in smart ticketing, and has developed some key technology we believe would be of great interest to OSPT Alliance members as they deploy fare collection systems based on the CIPURSE security standard.”

The CIPURSE open security standard addresses the need by local and regional transit authorities for future-proof fare collection systems with more advanced security than currently in use. Because it is an open standard, CIPURSE promotes vendor neutrality, cross-vendor system interoperability, lower technology adoption risks, higher quality and improved market responsiveness, all of which result in lower operating costs and greater flexibility for transport system operators.

“We welcome the OSPT Alliance as an affiliate member of ITSO, and look forward to their contribution in helping to ensure that public transport operators throughout the UK can continue to maintain the highest level of security in the smart ticketing systems they deploy,” said Lindsay Robertson, chief executive officer of ITSO. “We believe that by working with the OSPT Alliance, ITSO will be better able to supply its members with a more diverse set of card products, including AES-based products, which is a solution the OSPT Alliance can deliver off the shelf in the form of CIPURSE.”

About ITSO

ITSO Ltd. is the non-profit distributing organization that oversees the ITSO Specification for smart ticketing in the UK. ITSO helps its members to set up and run ITSO-compliant smart ticketing schemes, tests and certifies smart ticketing equipment to ensure it meets the ITSO standards and ensures the ITSO Specification is up to date and fit for purpose. ITSO operates the ITSO Security Management System (ISMS), a secure key management and distribution system specifically developed to enable ITSO-compliant smart ticketing systems to be set up.

About the OSPT Alliance

The OSPT Alliance is an international association chartered to define a new open standard for secure transit fare collection solutions. It provides industry education, creates workgroup opportunities and catalyzes the development and adoption of innovative fare collection technologies, applications and services. The OSPT Alliance was founded by leading technology companies, and membership is open to technology providers, transit operators, consultants, solution vendors, government agencies and other stakeholders in the transit ecosystem. For additional information, please visit www.osptalliance.org.

 

Network Rail using BigData and rugged mobile to improve their data analysis

Tonight’s British Computer Society (BCS) event in the Davidson Building opposite the Savoy in London was the first one I’ve attended for years. The subject was the Network Rail “ORBIS” programme which focuses on data asset management.

The attraction for me was three-fold: First, I’m developing a keen interest in the railways generally thanks to our work with ATOC RSP and second, because of Smart421′s focus on BigData challenges. Thirdly, the agenda mentioned something about specialist mobile apps, which is my main interest in leading our Enterprise Mobile capability in Smart421 which is backed with IBM Mobility solutions.

The slick presentation from the impressive Davin Crowley-Sweet and his team brought out the approaches to data as an asset and highlighted the challenges of modernising an organisation that still collects much of its information, such as survey data, on paper. The slideshow was “Prezi” style zooming in and out like a game of Angry Birds and contained a LOT of detailed analysis and roadmaps which made me glad I sat in the front row to try and take it all in.

My rough notes are summarised here but I believe the interested reader can learn much more about ORBIS (which has been “reverse-acronymed” with the name “Offering Rail Better Information Services”) from the Network Rail website. The first point to note is that this is not another BigData experiment but an extremely far-reaching business transformation programme, focussing on business processes and aiming to be business-led. There are very serious business benefits already being gained and (according to the paper linked to above)

the £327 million total cost of ORBIS is expected to yield £270 million in asset benefits plus £100 million per year in maintenance improvements.

An iPhone for every maintenance engineer

The company took the far-sighted step of giving every engineer their own ruggedized iPhone along with the request to use the built-in features as best they could to suggest what can be used. Not surprisingly, one of the most useful features was GPS, accurately pinpointing problems with rails. Then when engineering work comes along on the Sunday consigning us travellers to the replacement bus service the disruption should be minimised as engineers should be guided directly to the problem location. Taking photos with the iPhone of problems with rails was another obvious use and now there are Apps being developed (one per month on average) that can automate some of the data capture along with the photos. I asked the presenter Edward afterwards about the apps and he said there are now developments across other platforms and O/S to use other (perhaps cheaper Android-based) handsets. Having around 12,000 engineers with a ~£500 iPhone is significant cost although the positive aspect of the workers being given the desirable devices should not be overlooked.

These unstructured data inputs were combined with significant mapping data, collected using helicopters and cameras on trains similar to “Google Streetview”. I think they mentioned collecting a few Terabytes of data from each train journey that was recorded in this way. That is some BigData problem to deal with the analysis and Network Rail to develop some sophisticated decision support rules around which stretches of railway need maintenance work most urgently based on the data analysed around curvature of the line, weather conditions, etc.

Some 20,000 miles of track, 40,000 bridges and tunnels and huge electrical, telecoms and physical networks make for a highly complex set of problems to manage. The seven year mission focuses on 5 asset types: Fixed assets, Fleet assets, Topology, Topography, Unstructured data (schematics, drawings, etc). It has several defined stages, in stage 1 it asked “what?” and “where?” and continues in stage 2 to try joining up and optimising the collected asset data.

The Contribution of Data Analysis to saving lives

There is a strong emphasis on improving safety through improvements to data management; recommendations following rail disasters like the terrible Lambrigg crash in Cumbria, for which Network Rail are still apologising, said that the points failure could have been detected and fixed earlier with better data analysis. Literally a case of life and death software.

Davin answered questions after the presentation and made the very relevant observation that enterprises should manage their operational data in the same way as they manage any other (physical) asset: know what it is and where it is, monitor its quality, use it while it is relevant and when it reaches end of life get rid of it.

 

Survival quip delivers powerful lesson on technological change

Photo © Ciprian.d Stock Free Images & Dreamstime Stock Photos

As you already know from the blog 5 Dec 2012, as we were preparing to tell  the world about our Big Data capabilities, our CTO Robin Meehan coined a cracking one-liner:

“It’s not about survival of the fittest – it’s about survival of the best informed”

We liked it so much we decided to include it on our go-to-market materials.

Since then, we’ve witnessed some upsides such as how our customers have decided to deliberately ’think outside of the box’ to better understand their portfolio of brands and be better equipped to attract customers without canabalisation of other lines of business.

A great case in point would have to be Quotemehappy.com which is already taking advantage of the analytical power in cloud computing with Big Data on AWS to understand its brand and build its business.

Aviva launched Quotemehappy.com in August 2011. With a national reputation and strong brand in the general insurance sector at stake, they wanted to know how their multi-touchpoint cross marketing activities impacted each brand in their enterprise portfolio.

Smart421 was invited to assist.  Smart421 architected the Cloud instances using Amazon Web Services (AWS) and developed the algorithms needed to maximise the power of the customer’s own data and the Big Data analytical environment. This gave the business a level of insight not previously possible with traditional on-premise business intelligence tools and techniques.

And the customer was kind enough to go on record about what we had been able to do.

“Smart421’s Cloud architects gave us a head start on making Big Data real for us, including how business insights are really delivered, what the costs really are, and how the technology really works in our context. Their output contributes to how we differentiate ourselves in a crowded market.”

Keith Misson, Operations Director at Quotemehappy.com (an Aviva company).

Naturally, we asked if we could feature this on our website because it evidences the transformation effect of what a well architected IT strategy can deliver for a business.

(Why not share this case study with your colleagues and friends using short URL http://bit.ly/Wby5Y6 )

Big Data is a good example of how technologies developed for one use have been deployed for an altogether different use. I think that Robin’s original quip on survival has actually gone on to deliver a powerful lesson on technological exaptation.

 

Please Rate and Like this post, If you can, please leave a Comment.

 

If the world is going Big Data crazy then you need to know what it is, what it isn’t and what it means to your enterprise

The subcategory called Big Data is emerging out of the shadows and into the mainstream.

From left: Matt Wood, Chief Data Scientist at Amazon Web Services (AWS) with Robin Meehan, CTO at Smart421
Photo by Jim Templeton-Cross

What it is.

Definitions abound (who would have thought it? – quite usual in the technology market). For Big Data, we quite like the definition that originated with Doug Laney (@doug_laney), formerly META Group, now a Gartner analyst. It goes something like this:

 ” … increasing volume (amount of data), velocity (speed of data in and out), and variety (range of data types and sources)”

Gartner continue to use this “3Vs” model for describing Big Data.

Unsurprisingly, others are claiming Gartner’s construct for Big Data (see Doug’s blog post, 14 Jan 2012).

Still confused?

Put another way, Big Data is commonly understood to be:

“… a collection of data sets so large and complex that it becomes difficult to process using on-hand database management tools. The challenges include capture, curation, storage,search, sharing, analysis,and visualization. The trend to larger data sets is due to the additional information derivable from analysis of a single large set of related data, as compared to separate smaller sets with the same total amount of data, allowing correlations to be found to “spot business trends, determine quality of research, prevent diseases, link legal citations, combat crime, and determine real-time roadway traffic conditions.” read more on Wikipedia.

Big Data could be executed on-premise if you have sufficient compute and storage in your corporate data centre. And some do, especially some large banks, and with good success. Several solutions are already out there on the market;  Oracle’s Big Data Appliance is just one example.  But it does also beg the question “why would you” ?

If you don’t want the CapEx of purchasing more tin, or don’t want to gobble up capacity in your own data centre, then there are alternatives. For example, a cost model now exists with cloud-based compute and cloud-based storage (for example, think of Amazon’s announcement of 25 percent reductions in the price of Amazon S3, it’s storage solution) that puts Big Data in the Cloud well within the reach of all UK enterprises. A cost model like that islikely to win friends in procurement and in corporate governance as well as in IT.

Hinging on technologies including Apache Hadoop clusters, Amazon Elastic Map Reduce (Amazon EMR) and others, Big Data is delivering a degree of analytics and visualisation not previously possible at affordable levels.

Don’t just take our word for it, ask around. We could point you to other experts in Big Data, such Matt Wood ( @mza ), Chief Data Scientist at AWS.

What it isn’t.

Big Data isn’t business intelligence (BI). What I mean is that Big Data isn’t BI in any traditional sense of the term. It is altogether another level on from that. Granted that some tooling enterprises may own may be recycled for use in Big Data analytics. But it isn’t another species, it’s another race.

Big Data isn’t a lame attempt at reviving a management information system (MIS); those should be left to rest in peace.

What it means for you.

By now, if you’ve read this far, something should be niggling away at you that you could be missing a trick. I trust it won’t be those voices in your head again. But it might be your instincts telling you how Big Data could answer those tough business questions – y’know, those “I can’t be asked” questions that existing systems just cannot deliver.

Now, you would not necessarily get our CTO to come right out and say that Big Data is the next big thing. But evidence we are assembling so far does seem to point to a new capability to deliver. For those with an appetite to understand their business in new ways, Big Data is delivering tangible intelligence that lets them see new dimensions, new possibilities and new revenue streams.

I did get a full radar lock on something our CTO said in the summer. It was a throw away line at the time but it stuck with me and with others. So, when the time came to consider an appropriate go-to-market message for our quarter three (Q3) focus, we decided to wheel out his one-liner as part of our messaging.

“It’s not about survival of the fittest -
it’s about survival of the best informed”
Robin Meehan, CTO, Smart421 Ltd.

Making no apologies to Charles Darwin or evolutionists, the statement is resonating with decision makers in the enterprise space, not least those in the Insurance sector. Why?  Well, we think it is because a lot of the big insurers operate under many names in their brand portfolios.

The capability to see and understand impacts of brand activities, such as Insurance Quotes, delivered using Big Data analytics in the AWS Cloud, is illuminating new gains that would otherwise have remained out of reach.

Don’t forget – brand analysis is only one use case for Big Data in the Cloud.

If the world is going Big Data crazy then you need to know what it is, what it isn’t and what it means to your enterprise.

Agree?  Disagree?

UPDATE 05 Dec 2012 – Our economist friend Tim Harford  (@TimHarford) sent this hilarious tweet: The data do not lie. OR DO THEY? Muah huah huah! http://dlvr.it/2b2NS1

UPDATE 06 Dec 2012 – Robin and colleague Ben Baumguertel (@bbaumguertel) are attending the Big Data Analytics event in London today (organised by @WhitehallMedia ).

Please Rate this post and Like this post below. If you can, please leave a Comment.

 

Lessons from the CIO front line…

Tonight I attended a talk by Sainsbury’s IT Director Rob Fraser (hosted by the BCS ELITE group) – who was voted Computing’s CIO of the Year 2011 no less! Whilst I do rub shoulders with the odd CIO, it’s usually on a very specific topic so tonight was a great opportunity to hear some candid details of what it’s really been like driving through a three year transformation programme at Sainsbury’s, what the gotchas were, what he’d do differently next time etc.

So here’s some of his key pieces of advice and reasons for success:

• They used an architecture-led approach. This was music to my ears to be honest – I tend to oscillate between “(enterprise) architecture is the answer” and despair at the state of the architecture profession in practice, so this gives me hope. When he landed they had an architecture team of about 5, and to drive the transformation programme they grew this up to about 40 (with approx 500 staff in IT, excluding external delivery resources, that’s moving from a ratio of 1:100 to 1:12.5).
• He hired some key staff for the IT transformation from the retail side of the business, not from IT (but supported by strong technologists). The credibility of a business representative massively helped drive change through with the rest of the business, and enabled more educated push back on the inevitable attempts at scope creep. In fact, the whole transformation strategy was very people-focused.
• The transformation programme was tracked over a 3 year time period, and the original “plan on a page” was still in use as the benchmark to measure progress against every year (i.e. they did not suffer from a “stretching” programme), and the programme had a definite end. It started, ran, and finished – rather than the original objectives bleeding into other change activities and giving a fuzzy back-end to the work.
• “Time to value” for any delivery was limited to 18 months maximum – as most organisations just don’t have the attention span to concentrate on anything with a longer payback.

 

Everything you could automate with IT was completed by 1981

Office Printer
Photo: Frank Baron for The Guardian

I was reading some spam about how IT is really changing the business world today and it got me thinking. When I started work in 1981 everything was already run on a mainframe, so in my opinion the next 30 years of computing was not been about delivering change at all – it was just about moving things backwards and forwards.

In the first 15 years the only demonstrable changes for users was the location of their printer and their applications. Printing went from a computer centre, to a print room in their building and then on to their desk. Day to day applications moved from the computer centre to their desktop PC and then to a computer room in their building.

The following 15 years moved things about again. Moving the printer back to the end of the corridor and printing into colour; applications moved from the computer room back to a computer centre; printed documents moved from the filing cabinet to the recycling bin; the development team moved 5000 miles away; and finally our private experiences started to move from a close circle of friends to being publically available on the internet.

What next ? Every application is moving to a mobile device; data is moving to ‘somewhere in space’; and we’re even being encouraged to ‘bring our own device’ to work – moving the workstation to the home and back each day.

The future of work is rapidly changing and perhaps now, at last, we will have the next phase of true automation.

But I’m yet to be convinced.

 

Time for Real Design – stop the tacticals, start the strategic

“Simplicity does not precede complexity, but follows it.” Alan Perlis
Last week’s IIBA (International Institute of Business Analysis – London Chapter meeting, kindly hosted by Credit Suisse) revealed a wealth of opportunity.

While the financial markets are struggling with low growth, increased volatility, low margins, and the enveloping burden of increased regulation (e.g. Frank Dodds), the requirements for IT change still come…and come…to do more for less.

Any company in possession of an IT estate consisting of duplicated systems, application and interfaces (see Conway’s Law http://en.wikipedia.org/wiki/Conway’s_law), must be in want of simplification.

The opportunity… is to step back from tactical solutions and consider:

• the lifetime cost of the change for RoI calculations,
• how to leverage and re-use the existing estate,
• consolidating systems and ‘clean up’ of the infrastructure
• adopting standard data and methods

The cleaner the operating model, the easier it will be to:

• show regulatory compliance,
• find the truth in data
• ease estimation of the costs of Acquisition + Merger integration

When this also allows progress toward the architect’s Target Operating Model (TOM), it spreads a common language and understanding across the business.

So… the recommendation is to make time for real design, take steps towards the TOM, and reject the tacticals!

“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.” Antoine de Saint-Exupery 

 

SyncNorwich Testing at Google Scale

I managed to finally get along to Norwich last Thursday (18th October) for the latest in the SyncNorwich “Meet-Ups”. It was held at Epic Studios on Magdalene Road, famous for the cheesy Sale of the Century quiz show from the seventies which was hosted for years by Nicholas Parsons and included the first TV appearance for a certain Simon Cowell.

This meet-up included two groups: Daniel Wagner-Hall talking about Google testing and Simon Cromarty, presiding over a more interactive session on iteration planning in agile delivery.

I went to Dan’s presentation and it was an entertaining and informative talk which started off with him saying Google didn’t believe in testers, at which point a tester somewhere died… I had a number of thoughts during the session that I am putting into this post and wish there had been time to raise or discuss them but for now they will stay as my own opinions – for one I DO believe in testers.

Photos by Paul Grenyer and John Fagan

Some facts and figures from Google presented by Daniel are really quite scary:

- Google have 15,000 engineers in 40 offices

- There are 4,000 projects active, some of which result in technical debt and tests that end up being “flaky”

- the average team size is just under 4, and many are called Software Engineer in Test (SET)

- These teams make 5,500 software changes a day, averaging more than one per second

- The codebase has about 100 million lines of code. There is one code base all in one repository

- On average, 50% of the code changes monthly

- The “infinite grid” of servers is actually about 100,000 cores in a global grid

- 4,000,000 browsers are launched for testing (not all chrome)

- The complete suite of 5 million test cases are run 20 times a day, meaning ~100 million tests per day

Massive scale of change

In other words, there is a massive amount of change going on, with multiple diverse teams spread across wide geographies and complete testing all the time is just not possible. Through static analysis, Google document that there is no way a change in one component can affect another component test.

Some other points that I noted down included “Make clean” is considered a bug. Petabytes of output needs recreating in case of a complete rebuild and time stamps are not a reliable attribute so Google’s build tools take a hash of source files to check for changes.

Needs hermetic control

Incidentally, every tool is controlled in the source code repository so Google make developers use consistent versions of all the tools and can then increase consistency and productivity by copying of built artefacts. Copying outputs between builds is always better than repeating a build with distributed workforce and data so the incrementality of building can be small as typically at least 90% is already been built at that version, and with those versioned tools, in other words it is entirely reproducible (“hermetically sealed”) and is a strategy known as “Hermetic builds” which I confess I had to look up and found a really good descriptive blog by Jeff Brown (see the link). Having small, composable services is similar to feature flags, little “switches” in software that turn features on or off at runtime – see Pete Hodgson’s blog on using these in javascript (which incidentally forms a huge part of GoogleMail’s code base).

Managing test dependencies

Other slightly more obvious advice was to parallelise component builds by having small libraries of <15 files, which makes perfect sense to me… but it did make me slightly confused why tests on such built components would need to be re-run and goes against the component-based paradigm of testing in isolation (remembering that earlier it has been stated to run all tests for every change).

The answer was that test results are also stored in the build system and if there are no (dependent) changes the answer to the test is the same so get it from the cache.

Something that struck a chord with me was “Don’t test for all different browsers” – if there is a problem with the way code works on a browser then it is the browser’s problem. Many is the time that I’ve spent ages tracking down and fixing a display glitch that only appears in Safari or IE. This is a problem dear to me in relation to testing multiple mobile devices so maybe I need to understand Dan’s points better. I think Dan mentioned that Saucelabs provides the cross-browser testing as a service.

Other common problems can include glitches in tests related to authentication and sessions so “Don’t log in for every test, spoof a cookie instead”. I’m not completely sure about this but as long as there are a suite of test cases to specifically test the login and session-handling then I guess it can help simplify functional tests.

Quadratic increase in code and test arises in growing companies where hiring of new developers is roughly linear, and writing code is also linearly growing, hence there is a quadratic increase in code and tests that has to be allowed for in capacity planning.

The Build Cops

So what happens when builds and tests start to go wrong? Google have “Build cops”, people who investigate what is going on. What broke? Who broke it? and have the ability to Rollback and retry change. They also chase down “flaky tests” in quiet times. I thought Dan went on a bit about flaky tests and got slightly sidetracked in a discussion about flaky tests indicating flaky code.

Release often and twitter pants

One other obvious strategic change was to have more frequent releases, which arose because Google Chrome had problems with last minute commits before releases when developers wanted to get in changes they were working on but perhaps not totally happy with rather than wait a long time for a subsequent release. So my takeaways from this are to think very carefully about encouraging/enforcing developers to be even more diligent in designing and implementing componentised, provable code modules and just re-inforcing the agile manifesto principles.

Finally, another take-away that I’m taking back to the team is “twitter pants” which I am sure is not funny at all in the US but in the UK the discussion around “Labels in pants” and python in pants will surely cause a few giggles. This is a shame as the framework for controlling dependencies actually sounds really interesting and I’m thinking we could invent a similar tool and call it Smart Trousers in honour of the Trousers of Reality. How much different would that book series have been if it were called the Pants of Reality?

And as a very last memory, it was nice to see that real software engineers still sport beards and ponytails (at least in Norwich). Oh, and thanks to all the organisers and my employers Smart421 for the free beer.

 

5000 years to catch on

I thought that the mental comparison between construction and systems was something that everyone had in their minds when looking at the maturity of architecture (which has been recently the scope of a recent engagement for a client).

The other day I was talking to a fellow architect and it surprised me that he had never made that metal comparison, so I guess a couple of paragraphs on the topic could be interesting.

 

So here’s the key thought: we IT Solution Architects are professional equivalents to our counterparts in the construction world, the Architects… what a revelation! J

It needs to be clarified that what we ordinarily understand as a “real world” architect, the one that architects buildings, bridges, airports, etc. would be the equivalent of the Solution Architect in the systems world.

 

In IT we have another half dozen other architect roles (Security, Application, Integration, Infrastructure, Data, Business); those have also their equivalent in the construction world, but in that business they’re mostly known as Engineers (I guess the fact that constructions relates to tangible physical elements makes it more of an engineering domain). But effectively it is the same approach: as a Solution Architect is responsible for delivering a balanced system design that addresses the business requirements across the technology and operational disciplines and drags in domain architects as needed, the construction architect does the exact same thing: he brings in the Security Engineers, the Electrical Engineer, etc. and each of those professionals provide their input into the overall blueprint for the building in question.

 

It is important to highlight that the construction architecture discipline has been around for a very long time now, without being precise at least 5,000 years. And don’t try to tell me that while construction is indeed an old activity, architecture is not. Not true; it may have not been the mature discipline it is right now, but it’s been around for quite a while (think of the Chinese Wall, the Pyramids, the Coliseum, all those were definitely not architecture-less feats).

 

Obviously construction architecture has matured to incredible levels nowadays; just look for example how successful the construction work for the Olympics in London has been. The level of sophistication of the design patterns; the clear boundaries between the disciplines; the crystal clear definition of the design deliverables; the standardization of tools and techniques; the precision and control of delivery; the absolute repeatability and predictability of it all…

How I’d wish my work in the system architecture space would run under such advanced and controlled frameworks… How I’d wish that whenever I start a new project I wouldn’t have this hopeless feeling that I’m entering into unchartered territory again and again and again…

 

So what else is new? What is it so exciting about drawing this comparison? What’s the bottom-line?

Well, the bottom line is that I draw consolation in that IT Solution Architecture is in its absolute infancy, just short of 70 years against those 5 millennia!

So whenever I get frustrated by my project issues, by my inability to prevent the same issues to creep over and over again in my designs, by how frustrated my project team, my stakeholders and ultimately my client get through the whole process, I always bring this image to my mind.

The image is that I’m not the equivalent to those smooth and trendy architecture boutiques effortlessly designing incredible stadia with an amazing level of complexity; the image is that I’m more like that architect the pharaoh commissioned to build the pyramid for his mortal body so long ago.

I can very easily imagine and get sympathetic with the level of absolute difficulty that challenge surely was for that anonymous architect, and sadly or not, that image brings peace and quiet to my soul… J

 

There you go, 5,000 years of experience for my discipline to catch on but also a certainty that at some point in time we will reach that dreamed-of maturity*… though not all of it may come true in my life-time… shame!

 

As those architects of old were constantly told… “the damn thing it’s just a pile of blocks, it surely can’t be that difficult to put together?”

J

 

* maturity that will enable us to apply those exciting building architectural concepts. Like the design principle of “pace layering” (http://en.wikipedia.org/wiki/shearing_layers), that allows the architect to define the different components of the building in a way by which faster changing layers, like the floor plans or seat distribution, are able to slip and evolved unobstructed by the slower changing layers, such as the building foundations… right now in IT architecture these concepts are just mostly aspirational, but their time is coming. In our current maturity state all layers in a solution change every day, if not every hour, during and after delivery, and little consideration is given to create durable structures… it’s like we’re constantly tearing down whole buildings and replacing them with new ones. Which is obviously one of the strengths of IT in itself, the pace and depth of change that systems support, but we definitely need to learn to architect in ways that enable us to evolve our systems by renewing “facades” and “floor plans”, while keeping long lasting components underneath for longer periods, foundations that are able and ready to support the frequent change on top of them.

 

PS: I haven’t touched upon Enterprise Architecture in the article, my view is that EA compares to the city planning activities that our beloved councils across the country try to deliver for our cities… I guess in one specific space it seems IT has already caught up and is probably doing a better job than our real world counterparts!

 

PS2: when drawing my comparison to pyramid architects, I humbly think of the lesser pieces, the ones that haven’t stood the test of time, the ones built for the pharaohs no one remembers… I haven’t really architected a system that will still be around and that technology tourists will explore, analyze and admire 3,000 years from today… but watch this space!

 

News from the CIO front line

Just fresh back from CIO Connect ( @CIOConnect ) 2nd & 3rd October in London – and wondering how the topics raised effect our customers today ?

The best session for me was by Glenn Morgan of BA, where two key points stood out.

Firstly, that IT departments should see their “customer” being the same revenue generating customer as the business do – and not just focus on the “internal” customer.

Secondly, that IT should be part of the team developing a business strategy and not a follower – a follower that then has to catch up. That is just too late.

My recent experience is pointing to the fact that our most successful customers have already made the leap and see IT as a true enabler. They are encouraging IT to reach into the business to ensure initiatives are quickly translated into deliverables and there is a true ‘line of sight’ from the business objective to the application that hits the screens – be those screens 3½ or 100 inch wide.

That strategy obviously calls for more rounded people who can think more broadly than a raw requirements specification and are not frightened to contribute ideas directly to the business.

And that is really encouraging to me – as it describes the Smart421 team exactly.