enterprise architecture

Do Startups Need Enterprise Architectures?

Peter Cripps architecture , , , ,

And by implication, do they need Enterprise Architects?

For the last few years I have been meeting with startup and scaleup founders, in and around my local community of Birmingham in the United Kingdom, offering thoughts and advice on how they should be thinking about the software and systems architectures of the applications and platforms they are looking to build. Inevitably, as the discussions proceed and we discuss not just what they need now (the minimum viable architecture if you like) but what they might need in the future, as they hopefully scale and grow, the question arises of how and why they need to worry about architecture now and can’t leave it until later when hopefully they’ll have a bit more investment and be able to hire people to do it “properly”.

To my mind this is a bit of a chicken and egg type question. Do they set the groundwork properly now, in the hope that this will then form the foundation on which they grow or, do they just hack something together “quick and dirty” to get paying customers onto the platform and only then think about architecture and go through the pain of moving onto a more robust platform that will be future proof? Or do they try and have their cake and eat it and somehow do a bit of both? Spending too much time on pointless architecture may mean you never get to launch because you run out of time or money. On the other hand if you don’t have at least the basics of an architecture you might launch but quickly collapse if your system cannot support an unexpected surge in users or maybe a security breach.

These are important questions to consider and ones which need to be addressed early on in the startup cycle, at least to the degree that if an enterprise architecture (EA) is not laid out, the reasons for not doing so are clear. In other words has an architecture decision been made for having an EA or not?

No startup being formed today should consider that IT and business are separate endeavours. Whether you are a new cake shop selling patisseries using locally sourced ingredients or a company launching a new online social media enterprise that hopes to take onFacebook, IT will be fundamental to your business model. Decisions you make when starting out could live with you for a long, long time (and remember just five years is a long time in the IT world).

Interestingly it’s often the business folk that understand the need for doing architecture early on rather than IT people. Possibly this is because business people are looking at costs not just today but over a five year period and want to minimise the amount of IT rework they need to do. IT folk just see it as bringing in new cool toys to play with every year or so (and may not even be around in five years time anyway as they are more likely to be contract staff).

Clearly the amount of EA a startup or scaleup needs has to be in proportion to the size and ambitions of the business. If they are a one or two man band who just needs a minimum viable product to show to investors then maybe a simple solution architecture captured using, for example, the C4 model for software architecture will suffice.

For businesses who are beyond their first seed rounding of funding and are into series A or B investment then I do believe they should be thinking seriously about using part of that investment to build some elements of an EA. Whether you use TOGAF or Zachman or any other framework doesn’t really matter. What does matter is that you capture the fundamental organisation of the system you wish to build to help offset the amount of technical debt you are prepared to take on.

Here are some pointers and guidelines for justifying an EA to your founders, investors and employees.

Reducing Your 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. 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. The lower, in other words, are your technical debt interest repayments. For a scaleup this is crucial. As much of every dollar of your investment funding that can go on marketing or innovating your platform leads to an improved bottom line, more customers and overall making you attractive to potential buyers. This leads to…

Enhancing Your Exit Strategy

Many, if not most, startups have an exit strategy which usually involves being brought out by a larger company making the founders and initial investors rich beyond their wildest dreams enabling them to go on and found other startups (or retire onto a yacht in the Caribbean). Those large companies are going to want to see what they are getting for their money and having a well thought through and documented EA is a step on the way to proving that. The large company does not want to become another HP who got its fingers badly burnt in the infamous Autonomy buyout.

To Infinity and Beyond

Maybe your founder is another Mark Zuckerberg who refuses the advances of other companies and instead decides to go it alone in conquering the world. If successful there is going to be some point at which your user base grows beyond what you ever thought possible. If that’s the case hopefully you architected your system to be extensible as well as manageable to support all those users. Whilst there are no guarantees at least having the semblance of an EA will reduce the chances of having to go back to square one and rebuilding your whole technology base from scratch.

Technology Changes

Hardly an Earth shattering statement but often one which you tend not to consider when starting out. As technologists, we all know the ever increasing pace of change of the technology we deal with and the almost impossible task of keeping up with such change. Whilst there may be no easy ways to deal with the complete left-field, unexpected (who’d have thought blockchain would be a thing just 10 years go) having a well thought through business, data, application and technology architecture which contains loosely coupled components with well understood functionality and relationships at least means you can change or upgrade those components when the technology improves.

K.I.S.S (Keep It Simple Stupid)

It is almost certain that the first version of the system you come up with will be more complicated than it needs to be (which is different from saying the system is complex). Anyone who invests in V1.0 or even V2.0 of a system is almost certainly buying more complexity than they need. That complexity will manifest itself in how easy (or not) it is to maintain or upgrade the solution or how often it fails or under-performs. By following at least part of a well thought through architecture development method (ADM) which you iterate over a few times in the early stages of the development process you should be able to spot complexity, redundant components or ones which should not be built by you at all but which should be procured instead as commercial of the shelf (COTS) products. Bear in mind of course that COTS products are not always what they seem and using EA and an ADM to evaluate such products can save much grief further down the road.

It’s All About Strategy

For a startup, or even a scaleup, getting your strategy right is key. Investors often want to see a three or even five year plan which shows how you will execute on your strategy. Without having a strategy which maps out where you want to go how will you ever be able to build a plan that shows how you will get there?

Henry Mintzberg developed the so called 5P’s of Strategy as being:

  1. Strategy as Planning – large planning exercises, defining the future of the organisation.
  2. Strategy as a Ploy – to act to influence a competitor or market.
  3. Strategy as a Position – to act to take a chosen place in the chosen market.
  4. Strategy as Pattern – the strategy that has evolved over time.
  5. Strategy as a Perspective – basing the strategy on cultural values or similar non-tangible concepts.

For startups, where it is important to understand early on your ploy (who are you going to disrupt), your position (where do you want to place yourself and what differentiates you in the market) and perspective (what are your cultural values that makes you stand out), an EA can help you formulate these. Your business architecture can be developed to show how it supports these P’s and your technology architecture can show how it implements them.

As an aside one of the most effective tools I have used for understanding strategy and mapping and deciding what should be built versus what should be bought are Wardley maps. Not usually part of an EA or an ADM but worthwhile investigating.

So, in summary, whilst having an EA for a startup will in no way guarantee its success I believe not having an EA could inhibit its smooth growth and in the long run cost more in rework and refactoring (i.e. to reduce the amount of technical debt) than the cost of putting together, at least an outline EA, in the first place. How much EA is right for your startup/scaleup is up to you but it’s worthwhile giving some thought to this as part of your initial planning.

 

 

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.

Enterprise Architecture is Dead. Long Live Interprise Architecture

Peter Cripps architecture , , ,

ZapThink have recently been drip-feeding a series of ZapFlashes predicting the end of Enterprise Architecture (possibly allowing them to derive some further consulting/education business by creating a little fear, uncertainty and doubt). Here are some of their predictions and my thoughts. Comments welcome.

  • The secret to 21st century software innovation. Is, according to ZapThink, in harnessing the power of complex systems (i.e. rather than just enterprise-wide systems). A complex system is one that shows some form of emergent behaviour where the properties of the system as a whole exhibit behaviour that the individual components do not. Most people don’t get this confusing systems that are just complicated with ones that are complex. For me this is spot on. As the enterprise morphs into basically the whole of the internet traditional governance models breakdown. The boundaries of the enterprise can no longer be nicely defined and who is in the enterprise and who is not becomes harder to pin down. People who get this and who can successfully harness the “interprise” (my new word of the month) by using the positive effects of social networking etc will win out over the next few years. Of course this involves huge risks not least of which around how will enterprises keep control of their data and intellectual capital.
  • RIP enterprise software. Enterprise software as provided by the large package providers is seen as large and inflexible and not delivering on the benefits promised by SOA. Companies are finding themselves encumbered with expensive and hard to maintain software they can’t “bend” to do what they want. ZapThink’s take is that whilst enterprise software may have failed SOA has also failed to deliver on its promise of providing flexible business processes that can be quickly adopted to new needs. My take is that like everything else in our industry nothing is given chance to bed in before the next wave comes and sweeps everyone along with it. Many clients I see are still grappling with getting an effective process in place for developing traditional systems let alone service-based ones and definitely cannot deal with complex systems properly.
  • The beginning of the end for Enterprise Architecture frameworks. Architecture frameworks (especially enterprise ones like Zachman and DoDAF) are counterproductive to developing an effective EA strategy. These frameworks are inflexible, sometimes encouraging what ZapThink refer to as checklist architecture. Checklist architecture focuses on achieving goals laid down by the architecture framework rather than the changing needs of the business. True but having no framework at all leads to even greater chaos in my experience. A framework is a structure which is meant to contain relevant guidance and work products to deliver real-world solutions. Frameworks that become too theoretical are always doomed to fail as they should. I hope this forms the basis of something more relevant to the real world.

So how would I characterise “interprise architecture”?

  1. Interprise architecture recognises that it is not enterprise architecture that is dead but trying to constrain architecture by the bounds of the enterprise that is no longer achievable. The ‘architecture’ bit still applies, but not the ‘enterprise’ bit.
  2. Governance models need to recognise that this extended enterprise includes people and other systems that are not controlled by the IT department (people using social networking software who will periodically ‘overlap’ with the enterprises systems).
  3. The ‘architecture’ bit needs to take into account the fact that systems are complex (in the emergent sense of the word) and it’s not always possible to tie down the requirements in a nice orderly way. Indeed fully defining the requirements may be counter-productive and not allow emergent behaviour. Processes for developing such complex systems need to take this into account.

To be sure this is not a complete list. This idea is not yet fully-formed in my own mind and needs a bit more time to ’emerge’ properly. Watch this space as they say.