Just as the show could not go on without the dual act of Punch and Judy it seems this is also the case with innovation and technology. In a recent research article from Deloitte (http://dupress.com/articles/the-scale-paradox/) the linkage between cloud technology and the ability of small companies to be disruptive has been played out on the battle field of analytics.
Put forward as the scale paradox, this article looks at the role that Cloud technologies have in dismantling the scale advantage of established businesses. Cloud technologies have enabled new competitors to enter the market and challenge the incumbents with new and innovative business models. While this document focusses on the area of analytics we are increasingly seeing Cloud and the open/collaborative business models that Cloud promotes trumping traditional businesses on speed and agility.
It seems that whenever innovative businesses come calling technology is ready to answer. Similarly when technology takes a lead the innovative businesses are quick to embrace.
Given the clear advantage that agility brings in the current business environment one has to stop and ask whether it is really worth owning and controlling all that technology stuff when the guy down the road is leveraging the Cloud and responding so much quicker?
Are those clouds gathering over the IT department?
With the emergence of the cloud as an alternative source for IT services, organisations can now get very clear and predictable pricing for specific business services. As a contrast, many internal IT departments say it is too complex to calculate how much it costs to support a single business process. As the volume of business services in the cloud grows, this leaves organisations with a dilemma: should I do what is commercially right for my P&L , or should I support my own IT function? Should I side-step our inflexible and costly IT department and to contract directly with external vendors?
What does this mean to you as a CIO?
The post-digital era should be great news for IT – a chance to expand their scope of services and reinvent their brand as the business looks to technology to play a more strategic role. But fragmented IT processes and legacy systems of the 1980’s won’t allow IT organisations to effectively deliver on the changing demands of the business. IT should change its management disciplines to keep up with the pace of change and stay relevant against growing options for external fulfillment of technology services.
Social Media in the Enterprise – It’s Not Just Social!
Along with the much of the world, New Zealanders are big Facebook users. Over half of our population has an account and Facebook has even overtaken TradeMe (NZ equivalent of eBay auction site) as the most popular site for New Zealanders.
But the reality is that the power of social tools are generally not being exploited within our workplaces, and there is a fair amount of cynicism around their usefulness within the Enterprise. However, some organisations are starting to use Enterprise social media to enable more efficient, effective, and mutually useful connections between people, information and assets.
At Deloitte, we have several enterprise social media initiatives in flight, and recently deployed Yammer globally across our member firms. It is fair to say that in New Zealand, we also encountered initial challenges and I have to admit that I was also a skeptic when it was launched over a year ago.
However, there are now no shortages in stories highlighting the value that Enterprise Social Media has created in our own organisation. It is a tool that has allowed us to self-organise and solve problems in smarter ways – I’ve found hidden talent, shared project experiences, solved problems faster and increased collaboration across our different service lines (e.g., working with Enterprise Risk Services) though this medium. Yammer also allows many of our practitioners who are frequently on the move to stay in touch with their colleagues and keep up to date easily through their smartphones, be it at the airport, taxi, or bus stop. For an example of how Yammer was used by our Australian colleagues to overcome an odd set of challenges as a result of the Puyehue volcano eruption in Chile, click here. http://www.youtube.com/watch?v=YOjk1yR0ea8
Where do I start?
Social Media in the Enterprise is a journey and success cannot be achieved overnight. Unlike an externally facing branded Facebook Page, the tools need to enhance existing processes, tools need to be integrated to existing technologies, and business benefits must be defined.
Depending on where you are on the journey, here are some key questions to consider:
Envision. Will the social media vision stand on its own or be part of broader business objectives? What value can be generated? What is the high level business case?
Define. What are the priorities for enterprise social media? What are the capabilities and features users expect?
Plan. What processes need to be defined? How will content be generated? Who in the organization is likely to adopt social tools, and why or why not?
Tool. Can existing technologies be leveraged? How many vendors need to be engaged? Will tools be integrated with existing technologies?
Launch. Will a pilot group be used? How will functionality be rolled out? Will a coordinated social media branding effort be undertaken?
Grow. What can be done to encourage adoption and use? How will the deployed tools change and be refined? Who will the advocates be?
Comply. How will content be managed? Do guidelines need to be modified to accommodate a new way of business?
Govern. Who needs to oversee and monitor tools? What support structures will be put into place? How does enterprise social media stay relevant and top of mind? Measure. What metrics will be monitored? How will success be defined? How will ROI be measured?
We all recognise that part of the role of a technology architect is to draw lines and boxes. Whilst simple in nature, architecture diagrams are extremely powerful tools that help to structure complex problems, communicate ideas and solutions, establish a common language across disparate parties, and countless other uses. Enterprise Architecture & Solution Architecture has matured over past few decades to become pretty sophisticated and architects have also grown to leverage the advanced frameworks and tools we have today.
However, over the years, another set of lines are being drawn behind the scenes. Whilst also powerful, they are potentially dangerous and create barriers to effective progress. Examples of this may include the lines of segregation between architecture and other aspects such as project management (e.g. timelines, cost, resources), business analysis (e.g. requirements gathering), and change management. In the pursuit of architectural alignment and goals, we sometimes unwittingly segregate ourselves from reality.
Having been through 15 years of Systems Implementation delivery, PMO & Project Management, I’ve come to realise that the real art of drawing lines are about the ones left undrawn. As architects, I strongly believe that our ability to take on different perspectives across project managers, business analysts, developers, testers, business stakeholders and others is imperative for developing practical solutions.
The role of the architect enables us to freely engage with almost any stakeholder from the most junior to the most senior in the organisation. What type of lines are you drawing?
There are no prizes in the CIO game for spending lots of money on systems without creating significant incremental value to the business. And that’s why, in so many organisations, the need to respond to value creating demands can leave the IS function with little time or resource to maintain and modernise their existing systems. This challenge applies across the public and private sectors across the globe.
But there always comes a time when these systems reach the end of their life, and that’s particularly tough when they are your most integrated and complex applications. These systems can be too hard to maintain and change, inflexible and difficult to integrate, and the people who know anything about them may well have drifted over the horizon into retirement or to play with newer, shinier toys.
The challenge for CIOs is what to do about these legacy systems, especially when they are at the core of the business, holding the enterprise’s intellectual property, years of business rule development, and the organisation’s critical data. Add into the equation that these “core systems” are often at the centre of a complex spaghetti plate of interfaces and peripheral systems, and the challenge about what to do becomes even less clear.
As the generation of applications that were developed on mainframes using legacy technology approaches end of life, many CIOs face the question: “What should we do?” Do they really want to take on a gargantuan and risky programme to select a replacement system and to do open heart surgery on the organisation? Or do they plan out a roadmap of progressive modernisation which leaves the organisation potentially constrained for the foreseeable future and beyond?
Are those taking the progressive modernisation route really just putting off tough decisions, leaving the challenges for the next incumbent CIO to solve? Are major core system replacement projects just too risky and expensive expect where proven packages and implementation methodologies are available? Do re-engineering programmes to enable shifts to customer-centricity or service orientation really work?
Do you have a view? What are the key factors that a CIO (and the rest of the business leadership team) must consider to decide how an organisation should address the challenges of legacy? What preparation is required before a CIO can grab this nettle?
Is there really a debate to be had around BYOD (“Bring Your Own Device”)? Or is the only logical course of action for a CIO to be found in another four letter acronym: JFDI (“Just Focus and Do It”)?
I’ve heard so many the concerns about a loss of worker productivity, the risks about losing valuable data, what happens when a device is lost and what happens when an employee leaves but these are all issues that any organisation already faces through other existing events and channels. Nothing has yet convinced me that the risks associated with BYOD are so large that it should not be entertained by any organisation.
Every generation of new technology opportunities is burdened with its own slipstream of naysayers with scare stories of doom and Armageddon. Many of us will recall (and are possibly still battling with) the fears of allowing staff to access the Internet. Even worse was the spectre of data loss through exposing an organisation’s systems to the outside world. Further back, many will recall the convoluted mechanisms we used to follow to enable remote access to email. And the doom-mongers have warned of productivity hits and security issues when giving staff access personal access to desk phones, allowing the use of fax machines and even when installing photocopiers.
Don’t get me wrong – I think appropriate mitigation of risks is critical to the successful implementation of new technology – but I don’t believe that such threats should ever create overwhelming barriers to adoption.
CIOs should give up the battle of saying “no” to BYOD and get on the front foot in terms of how to make it happen. There is a wealth of expertise and learning in the public domain from those who have already embarked on this journey and product suppliers are rapidly integrating capability into their offerings. Even the monolith of the US Government is helping its federal departments get ready for BYOD: http://www.whitehouse.gov/digitalgov/bring-your-own-device. Don’t be the CIO that said “not on my watch” – just do it!
Through my recent experiences in solution architecture, observations in the workplace, and some interesting publications (http://amzn.to/MJYTNL , http://bit.ly/Qa84qh), I’ve come to recognise that the skillsets required today goes beyond the traditional set of requirements.
Credentials and experience with using Zachman, TOGAF, Archimate, UML and a string of other frameworks, tools and notations will only get you so far – and it’s often not enough to make a real business impact. In fact, if these frameworks and tools are used inappropriately, or too agressively with stakeholders, they could actually become barriers to effective communication – defeating a key purpose for which they were devised in the first place.
I’ve found that architectural connectivity with business strategy, the business case, business process, business risks and issues, and other organisational factors are essential – in addition to technology considerations. Whilst this may seem obvious, it isn’t necessarily second nature for some of us – depending on our career history. For example, is this business oriented mindset evident in our day to day interactions with our colleagues and stakeholders? When we are modelling architecture diagrams, are we incorporating some of these aspects directly on the page? How we are making the connections are important, and it needs to be easy to understand – by everyone.
The architect is sometimes viewed as a vital link between business and technology. What are your views?