Enterprise Social: Your Future Neural Network

If you’re reading this in the last months of 2014, it is likely that you belong to a company which has pondered enterprise-social platforms. And it’s likely that many head scratching moments have occurred and that the answers so far fall into broadly two camps.
External use and mining of social media is now well understood as a means to build customer engagement and feedback. Plenty of people still get this wrong but tools like Clarabridge are strong players in this area.
The more perplexing piece is the use of social platforms inside the business and here, most businesses have explored rolling out Yammer or Chatter and are often wondering ‘what next’? Many are actually struggling to justify what it is that they are getting out of this?
In the rest of this piece, I’d like to suggest that the Enterprise Social Platform is an idea whose time has come and that in 2015 we will all be flipping to the new model of enterprise social.
First though, let me highlight some of the problems of communications inside large organisations:
Information flows in big companies typically represent hierarchies. So information typically flows much more smoothly up and down hierarchies and quite poorly across these lines. This is just a truism of corporate cultures and represents a significant inefficiency.
Second, reward systems in most companies are typically not aligned to avowed corporate values. Many companies try to enshrine values such as collaboration into their work culture but have no means in place to recognise or reward such behaviour. Consquently, collaboration, or other such values, are often a road-kill in the stampede of those behaviours which are actually rewarded – often to do with sales targets and hard numbers. This is arguably detrimental to the business in the longer run, and this is specifically the problem that WorkAngel, one of the start-ups in this space is seeking to solve.
And how exactly do we measure the internal transaction costs of doing business? For example to create a proposal or to deliver a project, you might need to work with up to a dozen people from different teams and departments. Often the two kinds of transaction costs you encounter are (a) time to locate the right person and (b) the time and effort-cost of the transaction, given that the said person may have no idea about who you are and may have no motivation to support you. Again, start-ups such as ProFinda and WorkAngel look to solve these everyday problems.
Another challenge you face as you grow larger and more global, is the tendency of localised problem solving. Would you even know if the problem you’re trying to solve (say, a branch specific problem in a Bank or a retail outlet), has been solved somewhere else in the organisation? Or that the expertise exists elsewhere? Also known as the re-inventing the wheel syndrome.
Many people have written in recent times about the role of culture – often more important than strategy as a critical contributor to success of an organisation. Where does your culture reside? Where is it rooted? How do you create a crucible for capturing this?
Even more so when you go through mergers or acquisitions and you are trying to quickly forge a new culture, and all the earlier challenges reappear in starker ways.
And what about all the soft information that you increasingly need to hold and manage but have no repository of? Somebody in the team worked as a volunteer at a hospital and has the insight which could make a big difference to your healthcare project. But it’s not in her CV, or in your corporate systems. And all the conversations between people that hold ideas and sparks for new products. And that brainstorming session that could have been a product, but everybody got busy with a bunch of other projects? Where is all of that intellectual capital?
And a last but important challenge: we are today in the world of bring your own self. This is a term I first heard used by Ade McCormack while we were discussing BYOD. But the idea is ubiquitous – increasingly we are blurring, in positive ways, the line between personal and professional. We no longer have to leave our personalities and hobbies at home because increasingly those can represent pools of capabilities or knowledge that can add value to our work and to our businesses. We are being encouraged to bring our whole selves to work. And our information systems are inadequate to reflect and represent our whole selves.
So Where Do We Go From Here?
We know that we’re moving from systems of record to systems of engagement in most businesses. Implicit in this is a move from structured to unstructured information. And from data and transaction centric to relationship and conversation centric information. It also implies the move from desktop to mobile and from process based to context based information. John McCarthy and his colleagues at Forrester have a report on this.
Seen in this context the enterprise social platform is that new and complementary layer which holds this new conversation centric, context based, relation and human oriented information which seeks to address the problems we outlined earlier. There are two key words here. (a) Complementary – nobody is suggesting we junk our transactional and structured data in favour of the warm and fuzzy. and (b) seeks – there is no guarantee. A lot will still depend on that pesky notion of implementation.
Social platforms are inherently non-hierarchical. Although there are some like Loyakk, which are designed around certain types of hierarchies, most are designed to engineer those serendipitous or interest based discussions, or perhaps around specific problem domains which are independent of hierarchy. On a social platform it’s not just the HIPPO who get’s his/her way. (Highest Paid Person in the Organisation). So cross hierarchical and also cross departmental conversations become quite common on social platforms. I have found Yammer perfectly good for this kind of discussion. For example when I wanted to know how to create an internal enterprise blog, I had 3 good answers in about 30 mins of posting a 1 line question.
I’m excited talking to next generations social platforms, such as ProFinda and WorkAngel because they go to the core of the social challenge outlined above. WorkAngel, for example has a mechanism for explicitly identifying and rewarding those behaviours which align with the avowed organisational values, through a social feedback mechanism. What’s more the rewards can be quick and even financial. ProFinda’s secret sauce is the algorithm that goes to work on all your data both structured and unstructured, internal and external, to create relationship patterns which tradition tools don’t or can’t get. Both of these are softwares you license and install, so we mustn’t confuse Social Technologies with Social Media. Both of these have strong mobile platforms and analytics, so critical to today’s needs. As does Broadvision, with it’s Vmoso mobile solution which sits on top of the Clearvale social platform.
Beyond Platforms To Results
Needless to say, the best platforms will not be good enough to deliver success if you just treat them as the answer, by themselves. Some of the key, and often obvious guidelines:
It’s always useful to have clear and measurable business objectives. Following a discussion with one of our clients who wanted to implement a well known social tool, but didn’t have a clear business case, we drew up this mind map. The idea was simply to identify the different types of problems that could be solved by the tool in question, from providing support on HR issues or driving cross functional teams.
I would urge taking this further till you can see a clear path to money – either money earned or saved. You may not get clear answers but it will still provide clarity of thinking and enable you to get the right data going forward.
What we should avoid, is what the authors Macdonald and Bradley, in their book “The Social Organisation”, call ‘provide and pray’. Don’t just invest in the platform and hope some good will come of it.
But Can’t We Experiment With New Models?
Does this sound contradictory with the notion that with new technologies, you don’t always have a clear business case, and you need to try stuff? The key here, I believe, is that if you’re trying it out, it should be (a) a controlled experiment and (b) with specific learning objectives. So the learning becomes the business objective and backed by an understanding of the metrics of that learning.
Things To Avoid
(1) This is not an IT solution
(2) The product/ platform is not the answer by itself
(3) Avoid buzzwords like ‘gamification’ if they are not delivering your business objective.
Some Other Issues To Think About:
Can social experiences truly be engineered? Probably not a hundred percent. But they can be curated. And the right platform, with the right implementation underpinned by clarity of goals, will go a long way in getting you there.
Can true collaborations across hierarchies actually take place in large companies? Probably less so in high power-distance cultures. How you enable the voice of the junior most people in the business is definitely a part of the answer.
What about the work/ non-work balance?
This goes back to the point earlier about bring your own self. This is going to be one of the key debates as we move away from traditional office environments with clear time and place separation of work and personal. New mores and guidelines will evolve. It is entirely possible that people in err in both directions. This space needs watching and again, it won’t harm to gather data which can help to create those guiding principles.
In Conclusion:
Unless there is a specific need for point to point communications between people who need it, the publish subscribe model is a far more efficient way of communicating. Facebook has made us comfortable with the notion of a feed and thanks to social media platforms, we are all able to post, follow, engage and respond as we feel best. No education is required here.
If done right, the social layer will be the neural network of your enterprise. Not getting it right, though, will lock your business into the past and history is very unkind to anybody who doesn’t evolve.

Enterprise Mobility: 10 Lessons From The Last Three Years

From August 2011 to August 2014, I spent 3 years building up Cognizant’s mobile practice from scratch in Europe. Together with my colleagues we learnt a very large number of lessons, many of them the hard way – still have the scars to show for it! During this time, globally, we worked with an ever increasing array of clients, projects, partners, and challenges. From this collective gold-mine of experience, I’m distilling 10 key learnings. The number 10 here is arbitrary and could easily be 15 or 20. But here are my top 10. 


Worth mentioning, these learnings are not about how to build apps or solve technical issues, but about how Enterprises go about embracing mobility. 


1. The App Launch Is The Start, Not The End of the Journey 


Too many businesses bring out the champagne when the app hits the App Store, as though the job is done. This is a bit like an F1 team heading off to the pub after getting the car to the start line of the race. The real work may just be beginning. Especially if you’re focused on the actual business outcome and not just taking a narrow ‘IT approach’.  


Even if you just wanted to get the app launched, you would still be advised to wait for at least version 3. Invariably, the version 1.0 of the app will have a ton of assumptions or choices which will not withstand contact with reality. Often after a couple of iterations these have been weeded out, so you’re approaching stability by Version 3. 


In any case though, this is just getting to the races, as I mentioned earlier. You still have to do run the race – i.e. deliver the business outcome and program. Having a clear set of milestones around business objectives will enable you to think beyond the launch of the app. 


One of our clients had plenty of anectodal evidence about how the app was doing but it wasn’t something they were tracking any more. Consequently, they always found it hard to fund projects. Another client revised the application through the year continuously making changes and improving the user experience. Not only did the app do very well, but it created a tremendous business impact as well. 



2. Analytics Canot Be An Afterthought 


I once met a CIO who had to keep pointing to app-store ratings while presenting the mobile updates to his board, but still didn’t have analytics embedded in his app.


Everybody agrees the value of analytics and it’s role in the lifecycle of the mobile app. But all the head-nodding that goes on at the early stages of discussions doesn’t usually translate to actual investment of time, effort and money to baking in an analytics model into the early stages of the app. All too often, its treated as something that’s really important but ‘we’ll come back and fix this in the next version’. The next version never arrives, as you well know, for a lot of apps. 


The huge logical fallacy here is also, of course, that we will magically know what needs to be changed in version 2.0 or that we will be working off a frozen product roadmap, with no thought to what people are actually doing. 


The right way to do this is to think about the key assumptions that your app depends on (e.g. ‘users will check the app outside the home’) and build in data collection and analysis models that validate or disprove these assumptions. The latter is more critical to the improvement of the app obviously. 



3. Governance May Be More Urgent Than Strategy 


This is a very bold statement, but bear with me here. 


For many businesses there is a massive opportunity and innumerable opportunities to deploy mobile solutions. Trying to corral all of these into some sort of master-plan may be both unfeasible and counter-productive. And in most businesses, nobody is waiting for the strategy. As the saying goes, anybody in middle management with a budget is building a mobile app. 


There is a debate to be had about what exactly a mobile strategy implies. But given this situation, a more urgent need, usually, is to create a governance model around the dozens of apps being built right now, in your business, by big and small providers, and in very disparate environments. The governance process needs to define methodolgies, processes, gates and frameworks – around those aspects, such as security or middleware which will form the basis of your enteprise mobility strategy. 


The likely scenario is that all these apps will need to be integrated, maintained and enhanced. And the only way to do this with any control of costs and complexity is to ensure they follow published guidelines, no matter who builds them. 


I’ve met companies who have built over a hundred apps. They no longer have any control or even track of all the apps built, the amounts of money spent or what it is costing them to manage these apps, annually. There doesn’t seem to be any point taking about strategy in this situation. 



4. Structure Around MCOE To Get The Best of Biz & Tech  


The oldest truism in IT is that business and IT have to work hand in glove to ensure success. Yet, when it comes to Mobility, this is probably even more true, and very rarely followed.


The reason it’s more critical, is that mobility is a highly consumerised technology, in a nascent stage of maturity and lacks the standardized business case references of more mature technologies, with huge opportunities for specific innovations. A major airline we spoke with explained that converting a bunch of paper based manuals (which had to be mandatory carried on all flights) into iPads meant that the fuel savings across flights could more than pay for devices for the whole company. 


And the reason it’s rarely followed, is that there is also no clear standard for how mobility should be structured. In some businesses it’s a part of an omnichannel strategy. For others it’s driven by IT. For still others, it’s part of the innovations group. And others follow a bit of each. Often, Enterprise Mobility is owned by whoever has been brave enough to volunteer for the job. This is much more a marketing challenge than an tech problem. 


In the absence of a clear hierarchy, the MCOE is often a very good way to get the key people into the core thinking group. End user computing, IT and applications, security and compliance, marketing, line of business managers and HR and internal comms – all of these teams could potentially have a seat in the MCOE, in addition to architects and vendor managers. 


Analyst firms such as Gartner have argued that establishing the MCOE is the most important piece of your strategy. I would definitely agree that it’s a critical structure to put in place for the next 3 years, at least two of our global clients are well down the way towards establishing a Mobile COE. 



5. User Centred Engagement Redesign – It’s Harder Than It Sounds


There are two premises which put mobility projects completely outside the comfort zone of IT. They involve Engagement Redesign and User Centred Development. 


Traditional IT has usually put the application complexity front and centre. Large amounts of information being stored, retrieved and used by users who are themselves multi-tasking. The PC era has lasted for some twenty years and even on the web, much of the engagement has been PC led. Suddenly we are forced into a rethink. People aren’t coming to the website. They are engaging with you on social platforms, apps, or other new ways. The digital world is blending with the physical world. The problem is no longer about how to put all the information in front of the user, it’s actually how to get the user to stay engaged. Not just how, but why? And there is a great upheaval in progress that traditional IT has never had to deal with. 


The sharp end of this change, is the user centric development approach. The combination of consumer-grade technology and experiences, the shift towards engagement centric applications and focus on simplicity means that the entire development approach needs to be modelled around the user. This is not the black magic of ‘creative’ work, but the scientific application of service and product design principles, and ensuring that the user experience is what drives the features and app functionality. 


All of this makes it incredibly hard to reconcile this with traditional IT approaches. Be prepared to rethink a lot of stuff, if you’re invested in traditional IT processes. This is why so many businesses are still trying to work with digital agencies as well as systems integrators, to bring these worlds together. 



6. Mobile Strategy – Riding The Penny Farthing?  


All of this is not to say that strategy doesn’t count; it does. The question though, is: what exactly is strategic in this space? 


The biggest challenge that we’ve seen is what I would call the penny-farthing challenge. Your organisation is like the penny farthing cycle. The little wheel in front is the digital part of your business. Agile, fast moving, new features and releases every 6 weeks. The large wheel is the traditional part of your business. Slower, harder to move, locked into your traditional systems and ERPs. Nothing happens in 6 weeks. Yet, these two wheels have to move at the same speed, given that they’re part of the same entity. 


The answer lies in the gearing of course. The piece of the puzzle that ensures that these two wheels turn at their own speeds but the business as a whole moves forward in a cohesive manner. In your business, this is the all important middleware that allows these two wheels to turn at their own speeds. Getting this layer in, and getting it right is probably one of the most strategic decisions for enterprise mobility. Arguably, much more important than which apps to build. 


An energy company for whom we built a mobile strategy started with the idea of defining business cases but ultimately moved towards establishing a middleware platform as the defining area of the strategy. 



Penny farthing



7. Skills Shortage 


Certainly, one area of strategic importance is the skill mix. Given the speed of evolution of the technology, coupled with the surge in adoption, the team and skills you bring to the table can make all the difference between success and failure. Thus it is, that everybody is looking for those gilt edged developers, designers and architects who can build the path into the future. Customers, vendors and disruptors are all competing int he same skills market. 


You don’t need an army, but certainly the core team you put together is again, an extremely strategic success or failure factor. A number of disparate skill-sets are required for mobile success – from service design, to architecture, to device optimisation. 


As much as technical competence, the trick is in finding people who are comfortable dealing with the unknown, and capable of setting their own standards. 



8. Product Maturity Is Low. Plan for It 


Undoubtably, you will evaluate some off the shelf products – MEAP/ MCAP/ MADP or some variation of the theme. Cross platform tools, api managers, MBaaS layers – take your pick. Just remember that we’ve had 3 generations of products in the the last 3 years. And M&A activity abounds even in the nascent space. Feed Henry was just acquired by RedHat. Antenna was acquired last year by Pega. SAP and IBM have build up their product suites through acquisitions. There is therefore a risk that the product you choose may be acquired or merged/ morphed over the next 12-18 months. 


There is also therefore the high probability that you will discover in the course of your project that the product doesn’t exactly do what it ‘says on the tin’. This is not a pot-shot at product companies. It’s a reminder that you can’t get to the levels of maturity we expect in traditional products, because they simply haven’t had enough time yet, and the landscape keeps shifting. So planning for a few bumps in the project will help you save some sleepless nights. 


For one of our Nordic clients we faced a huge amount of trouble in trying to integrate an off-the-shelf middleware tool with an enterprise product which formed the back end. It almost came to the point where we were ready to walk away from the project to cut our losses, but fortunately the collective decision to stick with the project meant we stuck with it and it’s now a successful product. 



9. Over-Investing in Project Management Pays Heavy Dividends 


Taking the earlier point into consideration, along with the complexity of networks, devices, operating systems, business expectations, testing issues, and fast evolving user needs, you can not over invest in management of the early stages of your project. 


Project management is definitely more complex in many ways for mobile apps, than for traditional projects for the reasons above. I can certainly point to more than one excellent project which owes it’s success to the policy of over-investment in early stages. We hired a top notch project lead with specific product knowledge and his input helped reduce a significant component estimate by about 30%, in the course of a half hour call. This one incident itself made his involvement financially worthwhile and the early brought a lot of confidence from the stakeholders involved. The application in question is being rolled out across dozens of countries globally. 



10. Are You Ready to Di-Phy? 


Digital + Physical = Di-Phy (this is entirely my imaginative acronym)


Somebody defined the smart phone a while ago, as a remote control for the world. Increasingly, it is becoming the bridge between the digital and physical worlds. Traditionally, in the digital environment, you would be on a desktop/ laptop and in an information universe which was only loosely connected to the physical world. You might comparison shop for a TV for hours, but then you would take a printout to a real world store and struggle to match specific model names and numbers to the in-store variants. 


As everybody knows, the smart phone changes that and allows users to scan and compare from inside a physical store. Also, the point of search or sale is everywhere. Virtual and augmented reality models are blending the real world and the digital worlds. Add to this the presence of wearbles, sensors and the IOT and you have an emerging scenario where the line between physical and digital is increasingly blurry, and this opens up a white space for new business models and solutions that create entirely new value for users and customers. 


You need to be thinking about the physical aspects of your business – your products, your supply chain, or your distribution and retail, and look for ways in which the mobile phone can in fact become a point of access, management and control, of the physical environment. 



In Conclusion


As I said earlier, there are many more lessons we’ve learnt from the volume and diversity of the mobile projects we’ve undertaken. This is just my list of 10 that seem critical to me right now. I would love to hear your views on lessons learnt! 

Digital Transformation: From TOM to EOM

TOM / EOM – sounds like a soup you might order. But for the purpose of this discussion, put your appetite to one side, and think about Digital Transformation. 


TOM or the Target Operating Model is the staple of the consulting framework in transformation environments. The logic being, you have an initial operating model and you enter a transitional phase, driven by internal and external change, and you emerge with a new “target” operating model. It’s an excellent construct and very useful for delivering change. 


In the digital arena, though the idea of the Target Operating Model is challenged because of a number of reasons. 


Critically, it assumes that the change is a finite and one time activity. This is no longer true. Consider the landscape today. You enter a phase of virtualisation of your servers and networks, and before you finish that you’re in the middle of the mobility revolution. You combine cloud and mobility to create another transformation and everybody is talking about big data and social analytics. And then there’s the Internet of things, machine two machine and smart environments waiting to happen. So which points do you pick as the start and end of the change? And if you took this whole set as one change, would you even survive it?


And then, if the change is not a finite or a single event, what do you assume as your end state or ‘target’ environment? And if there is no target environment you can define, how can you create a target operating model? Would it not be outdated even as you were implementing it? 


There could be an argument that these individual technology waves do not affect the business model and are just technology changes. I would disagree with that. Yes, moving from one vendor to another, or upgrading from version n to n+1 is a technology change, though even those projects need to be seen as business change projects. But the waves of technology I called out earlier – from Cloud, to Mobile, to IOT are all pretty fundamental shifts – often creating deep changes in business models. 


To add to these problems, as this article in the Forbes highlights, many organisations undertake digital transformation without actually knowing what it is. Many don’t really understand the transformation, many others just see it as platform upgrades. 


So here’s the bad news, your digital transformation project is not a one time exercise, there is no target environment and so your target operating model may be in need of an update by the time it’s bedded in. 


The likely scenario is that there will be multiple waves of transformation. And here onwards they will all be digital (or at least until we come up with a new word). 


Which leads me to my proposition – that perhaps the right way to think about this is as an Evolving Operating Model, rather than a Target Operating Model. 


What would be the key features of an evolving operating model? Here are three key ones, though there may well be more. 


Building a change capability – at the core of this is the creation of a Culture of change adaptability. I’ve consulted for many organisations where the smallest change has to be handled with kid-gloves and is a source of anxiety and organisational stress. These are all big changes we’re talking about, so there’s a lot of work to be done to make people change friendly. This should ideally be reflected in contracts with employees. HR needs to take a leading role here and ep build a culture of change through awareness, education, self-empowerment and counselling. At the same time, leadership needs to invest by ensuring the right people are chosen and then given the time to grow into this change culture. Based on my experience, there are parts of the world, such as Europe, where this would be a harder process than, say, in Asia. European business cultures are much more rigid about roles and function, and these are often defended by regulation. Also, in Europe, there is often a much higher premium on matching exact experience to a role, rather than bet on adaptability. One of the ways to address this is to balance the majority of such fixed role people with a handful of adaptors – people who can foster a pro-change environment within the business. 


For example, I met a European company in the travel segment who could not even change business rules in their enterprise apps, or implement a mobile app store without validating the decisions with worker councils. 


Funding Change: Not a capital expense but the cost of doing business: Build in the cost of change into your cost of running the business. Rather than the one hit capital expense of a digital transformation project, budget for change annually, that LOBs and divisions can draw from, with the right checks and balances to ensure governance is provided. There is every likelihood that each of the next five years will require significant changes to some part of your business or the other. Rather than running it as a giant centralised project, or leaving this to individual departments and LOB’s who may not value this investment, organisations should explore creating an investment bucket which is made available to teams based on their justification, against a stated vision. But this investment is locked down for change efforts and cannot be used for other purposes. 


Earlier this year, the BBC announced a program of saving £48m and reinvesting at least £29m of that into Digital Transformation services across channels, mobile and digital journalism. Cooperative Bank had set aside £500m on IT alone, to enable it’s digital transformation. Your budgets may be comparable to BBC, or Cooperative Bank, but in all probability they represent significant amounts of money. 


The big bang approach assumes that one large and hugely diverse project is the best way of optimising the way this budget is spent. Reality may be very different. 


Instrument your company: Build an instrumented organisation where process change can be systemised easily, using BPM, middleware, SOA, and other architectural approaches. This is fundamental in order to plan, implement and measure change. For example, if you want to change your mobile customer service layer, with new processes without necessarily having to make big changes in your CRM or ERP systems, you need a decoupled approach that will allow you to modify or even replace your mobile front end without always having to change a legacy application. But also, it will be faster and quicker to implement a new process if the systems can change quickly, rather than become a symbol of the organisational inertia. 


A good analogy and one you hear often in business discussions is about turning the tanker. We talk about large businesses being like large tankers – hard to turn. But your digital transformation should not be seen as that one awkward turn. It’s more like suddenly being in an environment where you will need to turn and often. The real challenge here is actually, how do you stop behaving like a hard to turn tanker? 

Why Digital Architectures Matter – A Business Perspective

I was recently in a discussion about digital architecture. There were half a dozen people in the discussion and everybody had a point of view, but there were two things prventing the discussion moving forward. The first was that we didn’t have an agreed view of digital architecture – a ‘what’. And the second was we didn’t have a ‘why’. 


My knowledge of technology architecture is limited at best. You would not want me anywhere near an actual architectural design discussion. But it was the ‘why’ question that fascinated me. Why is this relevant? Why should we bother discussing this? What’s at stake here? 


Let’s take a look at the competitive environments we live and work in. Increasingly, we are finding ourselves in a world of hyper-competition. What do I mean by that? 


First, we are competing on new parameters. Most industry leading businesses have done the basics, so the battleground for competition has shifted. Often the differentiation itself comes from an information driven or ‘digital’ part of the service. Last month, in New Jersey, US, I agreed with a colleague that a primary basis for choosing a rental car would be the quality of the SATNAV system. But it is also likely that you have done enormous amounts of optimisation on your operational models. I just read about UPS’s optimising routing by minimising the number of left turns (in the US) and their innovation on how to land cargo planes. 


Second, we are competing with entirely new types of players. Broadly there are 2 new types which require us to think harder. The first is the entry of established providers from other industries. For example, traditional banks have to worry about retailers many of whom are launching banking services. The second is the emergence of disruptive start ups. Once again, for Banks, you have new providers like http://www.simple.com or Square – each of whom may individually survive or perish, but collectively, they will pose some serious threats to your business model. 


Consider two more key trends: 


One, technology is now a part of the product. Almost every product. You can call it ‘smart’ or you can hide the technology but the chances that the tech component of your product is increasing annually as a percentage of your product’s value are extremely high. From Nike to Nest, everybody is doing this. 


Two, there is an ongoing service-isation. As most companies seek that sweet spot between pure products and pure services, technology, and specifically software, is often the delivery mechanism for the service component. After all, when you buy the Nest thermostat, what you’re really buying is the service of ambient temperature at home. Or when you buy a washing machine from Samsung, for example, you’re really buying the service of cleaning clothes. So could Samsung theoretically also send you analyses based on weather to let you know when clothes will dry faster without a dryer? Or perhaps it might analyse the performance of your washing and let you know that you’re overloading the washing machine on weekends. You can easily think of ways in which almost every product can enhanced by a service layer, which is driven by data and software. 


What does all this mean to our discussion on digital architectures? Here are some questions to ponder: 


1. If your competitor provides any core service at a lower cost than yours, could you survive in the long run? If a broadcaster can run a channel at 10% lower operating costs, or lower ad-sales costs by 10%, can their competition survive? Does your architecture allow you to run core services at a competitive cost model? 


2. If your competition can get new services to market faster than you can, would you retain customers? 


3. How do you compete against companies that have no legacy? You can get away in an internal discussion by talking about how much of a challenge your legacy is, when it comes to making changes or adding a new service. But do your customers care, when they can get the same thing elsewhere? 


4. Is your digital architecture designed to handle the new requirements of competition, new services, and the technology component of your products? 


So coming back to the challenges of digital architecture, I believe there is an absolute requirement set and a competitive requirement set. The absolute set may contain things such as scalability and response time. We learnt from the early days of the web that traditional architectures and spikes on websites were not a match in heaven. Even now, major sites crash when the world flocks to see something unfold or buy something everybody covets. Architecture that can handle spikes is a critical requirement in an absolute sense. You can estimate the boundaries and plan for them. Speed/ response time is another – we did a project once where it would take a few seconds to respond, and that was unacceptable, of course. After due analysis we discovered that each request was being routed via enterprise servers across the atlantic and back, so obviously even the physical set up needs to be understood. Other absolute requirements may include security and handling specific functionality such as streaming or transactions. 


But to my points above, all of this will point to navel gazing unless you also consider your competitive requirements for your architecture. This leads to benchmarking the costs of key processes, the time taken for changes, new products, upgrades and of course, your customer interface.


So whether you’re like UPS – extracting the last bit of efficiency so you can be that half a second faster than the competition – or whether you are the competition to UPS, the focus of your digital architecture needs to be (a) ensuring it can do all the things you need to do for your customers and (b) ensuring it allows you to be compete – by making you faster, cheaper, quicker or better. 


That should be the starting point of the discussion for digital architecture.