The IT industry is undergoing a seismic shift. Unlike previous technology revolutions, the changes to the way services are delivered to organisations and end users is forcing dramatic changes to the way organisations view technology, and how they are structured to deliver IT services. Change is happening, and how organisations choose to react to that change will determine their future relevance in the marketplace. What is driving this change, and how can organisations, specifically IT departments adapt and thrive?
I was watching an article on the news the other night that talked about IP-based messaging platforms (like iMessage) replacing trusty old SMS. The recent acquisition of WhatsApp by Facebook for an eye-watering $16 billion USD shows just how much belief major industry players have in growth opportunities around this segment of the market, at the expense of ‘legacy’ telecommunications providers.
In the same way that telcos are seeing their role being relegated to a commodity provider of a ‘dumb pipe’ for home and mobile broadband, those in the traditional IT infrastructure space are also at risk of having their lunch eaten by external competitors who can now deliver what was traditionally a complex service as an on-demand utility. Cloud infrastructure is transforming delivery and operation of servers, storage and network devices into ‘dumb infrastructure’ commodity services.
Today, few IT departments have the depth and breadth to design, develop, test and operate an entire suite of enterprise applications. The rise of ‘off the shelf’ enterprise software over the last 30 years demonstrates the validity of a model where much of the heavy lifting is provided by an external vendor when in house-capability does not exist, or an organisation chooses to focus its limited resources elsewhere. In recent years we have seen this approach extend further, to a full Software as a Service (SaaS) delivery model where all aspects of the software development lifecycle are managed by the service provider.
The progression of software delivery towards SaaS points to the future of IT infrastructure within an IT department. Rather than build and operate infrastructure using ‘off the shelf’ servers, storage, networking and operating system components, a range of Infrastructure as a Service (IaaS) offerings are available on-demand. IaaS increases the responsiveness of technology to business needs, provides cost reduction opportunities, and delivers a better quality service while shielding customers from the complexities of service design, delivery and operation.
The benefits of IaaS are often the same attributes used by IT departments to justify their existence to the business. If one of the core capabilities of IT is no longer perceived to be of value, how can it continue to remain relevant to the business? Transforming IT from its current role as a service provider to one of a service broker is one such way to retain relevance. While some technical skills will remain relevant, especially those related to security, integration and data management, others such as system design, delivery and operation will recede in importance. The real shift however is moving away from a focus on technology towards a consultative model where IT works as part of the organisation to deliver business outcomes. An increase in skills relating to business processes, requirements analysis, the management of commercial agreements, and most importantly, the successful management of the intersections between business and technology will be required by tomorrow’s organisations.
Change of such a scale is not easy, and requires understanding, planning and commitment at the very highest levels of an organisation. Those that are able to successfully make the transition will reap the benefits of utility computing and flourish in tomorrow’s environment. Those that hold tightly to old operating models may find themselves like many of today's telcos - a service provider without a customer.
At first glance, documentation may not be the sexiest topic for any IT professional, however it is often the standard by which our efforts are judged, especially by those that encounter our work after we have left the organisation. Few things in the life of an IT professional can be as frustrating as attempting to understand or support an IT system without having the required information available.
The standards of documentation I’ve encountered over the years vary wildly, and sadly many represent an afterthought of an otherwise talented developer, analyst, or architect. A solution is immediately more accessible and understandable when well-written documentation is incorporated as part of the solution. This in turn increases the value of both the service, and also of the writer. Creating well-written documentation should be a foundation skill of any architect, systems engineer or software developer.
I've encountered a number of projects and clients with differing expectations around how information should be captured. These range from engagements where the majority of time was spent writing documents to adhere to strict standards, through to projects where documentation is almost a foreign concept, and critical knowledge about systems is trapped in the minds of people who one day will move on, usually taking that knowledge with them. Even with more projects moving towards agile delivery methodologies, documentation remains an important component. What are some key tips to keep in mind when crafting good technology documentation?
1. Relevance to a wide audience
Can you as an author say with complete confidence that you know everyone who may want to make use of your documentation? If the answer is "no" (which it often is) then cast your net as wide as you possibly can before you start to sacrifice the truly important messages that you wish to convey. A document primarily aimed at a technical audience can with the right approach be just as useful to non-technical readers. In doing so you can not only increase the relevance and value of your documentation but you can also cut down on duplication - "one document to rule them all" is surely better than spending time and effort creating two or three audience-specific documents.
2. Forsake detail for the sake of brevity
Sometimes it can seem like a good idea to exhaustively document every nuance of your solution - you never know when you'll need to refer to it right? Realistically though, just how likely is it that you or another reader will need to know that the SSH service is set to start automatically on boot (which was the default anyway) - Can't they just look up the vendors online documentation for that information?
If you try and document everything it becomes tiresome to capture, almost impossible to maintain, and the messages that truly matter (like the fact that you must allocate at least 20GB of swap disk) get lost in the noise. Focus your documentation on the non-default decisions of your solution. Presumably each of these decision points is in some way justifiable, so provide the reason ‘why’ they were changed as well as ‘what’ needs to be changed. For those circumstances where it is useful to have a comprehensive configuration options documented, consider an appendix, or even better, make them part of build or deployment scripts so that they are truly reusable.
3. Standing the test of time
Let's be honest - most systems outlive their intended lifespan by a number of years. Dive into design and operational documentation for an enterprise application and you'll encounter a lot of information that is past its use-by date. Normally this relates to the attributes such as server names, operating system versions and such that at first glance seem to be reasonably static, but actually have a fairly highly chance of changing over a long period as components are upgraded and dead servers are replaced (virtualisation and IaaS complicates this even further).
In theory, documents should be updated when changes occur but in reality this rarely happens. However, most organisations today implement some kind of configuration management database (CMDB) to track IT assets. Linking to a service's CMDB entry in the documentation is a better way of providing up-to-date information about changeable infrastructure elements.
Documenting organisational structures, roles and personnel can be just as risky. Organisations change over time, as do the people that perform specific functions. When the need arises to capture this information, consider the role as well as the person, and to ensure longevity make sure you provide a description of the role. This way when "Systems Administrator" gets renamed to "Technology Service Availability Manager" after a particularly energetic round of corporate re-branding you can still track down the right person.
4. First impressions count
Nobody likes an ugly document. Bad fonts and formatting issues can turn people off just by glancing through the first few pages. Most people learn through visual stimulation, so support your text with diagrams where appropriate. Take a look at professional websites and published documentation for pointers on how to structure a page in such a way that it is easy on the eyes and draws the reader in.
5. Use everyday language
This point has been hammered home so many times over the years, but it seems the powers of business pseudo-speak are strong. Throw out jargon like "synergy", "moving forward" and "leverage" like old ham. Once ingrained, this habit is incredibly hard to break and even this author falls back into referring to "deliverables" and "low-hanging fruit" without thinking.
The problem with this type of language is the emptiness of meaning. Jargon stands in the way of proper expression, and in the worst case, can be used to intentionally obscure facts and information. Technology is precise, unambiguous, and definitive. All things that jargon isn't.
We in the technology sector more often than not work in an abstract world. You can't hold software in your hand. Nowadays we rarely have the opportunity to even touch a server, storage or network component. Documentation is the bridge between the abstract and the real world. Rather than treat documentation as an afterthought, we should write with pride, and use it as an opportunity to increase the value of the solution and a chance to close the gap between technology and people.
Rapid adoption of cloud technology worldwide has meant that many New Zealand organisations are already testing the water by shifting non-critical workloads to the cloud. However, when business-wide applications move into the cloud, they need to integrate not only with on-premise systems, but also other cloud services.
Our experience with New Zealand businesses has shown that integration is a key concern for those organisations considering cloud service migrations. This post explores the 5 top cloud integration problems and how IT Architects can address these when considering the implementation of cloud services.Top 5 cloud integration problems1. Fewer Integration Options
Often the options for integrating with a cloud service are dictated by the cloud service provider. While traditional batch file transfers may be supported, we find in most cases cloud service providers rely on APIs of various flavours. For organisations without a Service Oriented Architecture (SOA) capability or the ability to provide message translation services, successful cloud integration will require significant investment in your teams cloud architecture skills and experience.2. Poor understanding of data flows
We find that organisations often do not have a clear understanding of the nature and extent of information that will be stored in their cloud service. Not only do cloud services hold your information outside of your organisation, but many services also require access to your on-premise systems, potentially exposing you to a range of security risks.3. Ad hoc approaches to integration
Many organisations approach cloud integration on a project-by-project basis. However, as cloud adoption increases across the enterprise, this ad hoc approach to integration increases architectural complexity and overheads for the entire organisation that becomes increasingly hard to maintain and enhance. Project based approaches to cloud integration will result in ongoing costs remaining high, eroding the benefits cloud services can deliver. 4. Lack of suitable tools
The capability to integrate systems using SOA or custom APIs is something that many New Zealand organisations still lack. Many older on-premise applications have APIs that were developed prior to the emergence of cloud services and may be incompatible with newer, cloud-centric standards. In addition, some internal systems were not designed with any integration in mind, making successful cloud integration even more challenging. 5. Latency and performance
Due to New Zealand’s geographic location, cloud service providers are usually based halfway around the world from their kiwi clients. This raises concern around the ability of the provider to support the needs of their clients, such as reliable delivery of synchronous, near real-time communication.What can New Zealand cloud architects do to mitigate these problems?
The following 5 approaches can be used to overcome some of the cloud integration problems your organisation may be facing: 1. Create an integration strategy
An integration strategy should present a structure of how your organisation will approach the integration of cloud services. It’s vital you apply your strategy at an enterprise level to ensure all areas of the business are accounted for.
Practical guidelines directing standards and protocols for data transfer that are specific to your business should be included, with close ties to any existing identity, data classification, and information security policies. Standardised integration patterns should also be developed to enable a faster and smoother design and delivery of the solution.2. Establish a shared integration platform
This demands a move away from integrating on a per-project basis, towards establishing a shared set of integration tools. Functions such as message, routing, translation and transformation are required to move data between systems that may not speak the same language.
This means SOA gateways and message busses shift from “nice to have” status to key components of the IT service portfolio.3. Balance flexibility with complexity
A good strategy should provide solid guidance but allow for flexibility to meet the needs of specific projects and systems. One of the key objectives of strategic integration is cost reduction, so ensure you don’t erode this benefit by defining unnecessary levels of detail and complexity in your integration architecture.4. Understand your data
A good integration strategy leverages the knowledge an organisation has of its information. Make sure that your organisation comprehends the importance of its information, regardless of whether it is stored on-premise, in cloud services, or transferred between systems. This will enable the appropriate levels of control and visibility to be put in place, reducing threats to information security in a manner that fits the context and objectives of the business.5. Don’t forget identity
Many organisations focus on data integration whilst forgetting the importance of identity integration. The result is identity fragmentation across your services, with users having to juggle multiple usernames and passwords. Through directory federation or identity replication, organisations can retain control over who accesses their cloud services, and provide a better user experience.
The uptake of cloud services is set to accelerate in New Zealand over the coming years. Cloud integration will continue to slow cloud adoption and the realisation of cloud benefits until we start taking a more strategic and enterprise-wide approach. Creating an integration strategy and establishing a shared platform that is right for your organisation will help you efficiently and effectively transition to cloud while maintaining the necessary control over your organisation's critical information.
Many New Zealand IT professionals fear moving out of their comfort zone. However, having a successful IT career is about more than ticking boxes at your annual performance review. It’s about taking risks, grabbing opportunities to grow and surrounding yourself with a great team from which you can learn and develop.
So how do you take the initial steps to commence the journey to accelerate your IT career? This post identifies the four key steps all IT heroes setting out on their journey will experience along the way. Don’t worry – every hero reaps reward in the end.
1. Yearn for something more
The first thing you need to identify is what motivates you. This will help you to understand how to accelerate your IT career in the right direction. It might come as a surprise, but often we are not as motivated by money and status, as we are by the intrinsic motivators of Autonomy, Mastery and Purpose.
Autonomy is the desire to be self-directed, to manage your own time. If you are new to your role or new to your organisation, this most likely applies to you. You desire to move from ‘beginner’ status to ‘intermediate’.
- Mastery is the urge to make progress and get better at something that matters. If mastery motivates you, you might think of yourself as a perfectionist. You might want to craft beautiful code or design elegantly simple architecture.
- Purpose is the yearning to do what we do in the service of something larger than ourselves. If purpose is what motivates you, you will be motivated to make the world a better place.
Once you have identified your motivation you can begin your journey pointing in the right direction. However, every hero needs a sidekick or two to guide them along the way.
2. Surround yourself with support
Start looking for people to fill the roles that can drive your career forward.
Ideal mentors are people who you respect and admire because of the achievements they’ve had in their career. Selecting a mentor that has successfully been through the journey you are about to take makes sense. A mentor doesn’t need to be someone that works in the same industry as you, as they should be guiding you around personal development and how that can shape your professional career, rather than advancing your technical skills. Think of the relationship as helping to establish your personal brand.
In addition you need to identify a performance coach. Unlike a mentor, a coach is task-oriented so the focus of this relationship is on concrete issues like closing a skill gap. This means coaching is a short-term relationship as it only lasts as long as that gap is present. Your line manager, your peers, books & webinars and classroom training all could be great choices to fill the role of performance coach on your journey.
Industry networks are highly valuable resources when looking to accelerate your career. Mixing with people that share the same passion for the industry you operate in can open doors to mentorships, coaches, training and career opportunities. Joining an industry body in your chosen field should be top of the list in order to expose yourself to new experiences and make valuable contacts.
Lastly, as you journey into the unknown, you will inevitably pick up more skills from your experiences. Setting a benchmark of your current capabilities means you will have a better sense of your progress. Having a clear picture of your current skill set will also help you identify the capabilities you want to grow. Don’t be a jack of all trades – aim to be a master of some.
3. Commit to change – navigate through trials to triumphs
Stepping out of your comfort zone will be tough. You will experience setbacks along the way, so it is useful to try and identify what challenges you will face, so you can best prepare for them and not let them throw you off course.
The reality is that if you want to accelerate your career, you have to accept that a level of sacrifice is required in terms of your personal time and monetary investment.
- Failure is inevitable. If you want your career to be on a different trajectory than it is now, you are going to have to try new things and you won’t get them right first time. When you learn something new, and practice applying it, your performance will get worse before it gets better.
- Being knocked back from an opportunity you felt should have been yours (a new project, a new job) will dent your self-confidence. The best solution is to learn from the experience. What could you do better next time? This is also a good time to call on your mentor.
Remember, to guide your through this often uncomfortable process is your mentor, your coach, and the industry network you have built. Progressing through these challenges you will develop a clearer vision for your future, and you’ll know what gets you out of bed in the morning. Most of all, having fought through your trials and successfully accelerated your IT career, you’ll be more confident in your abilities to continue to grow and change.
4. Embrace your new hero status
On completing your journey it is worth taking time to reflect and examine the experiences gained. Success achieved on the hero’s quest can be life-changing, for you and often for many others. Knowledge picked up along the way instils higher engagement, greater job satisfaction, stability and higher performance, resulting in an enriched work life.
Reflecting on the initial motivations that guided you, you will discover that you have earned greater autonomy, mastered a new skill or domain or will be doing more purposeful work. You will now be in a good position to mentor others on their journey and after a rest, you might even be ready to head off again!
You know the story…
Bilbo Baggins, a little Hobbit, is an unlikely hero. Yet the wise and resourceful Gandalf convinces Bilbo to join him and a band of dwarves on a journey into the unknown to reclaim a vast treasure from the dragon Smaug. What follows is an epic adventure filled with dangers and near insurmountable challenges. When Bilbo returns to the Shire he is a transformed Hobbit. In the words of Gandalf “if you do come back, you will not be the same”. Like Bilbo, we all need to leave our comfort zone from time to time to take a journey that transforms us…
Are you ready to take on epic projects and face near insurmountable challenges as you identify, describe and deliver the changes required to solve complex business problems? You may not succeed on these journeys alone. Bilbo had Gandalf, Thorin and many others who contributed to making his journey successful. On your business analysis journey, Equinox IT is your Gandalf…
We’ve worked our magic to launch a new course ‘The Practical BA’ to help you accelerate your business analysis journey and overcome many of the inevitable challenges. This highly pragmatic course for new and intermediate BAs is delivered by our expert BA practitioners and covers the why, what and how of business analysis. Applicable to any project methodology, we’ll show you how to structure your analysis activities to ensure that you produce solution requirements that fully represent the business goals and the change required.Start your journey with The Practical BA
- 27-29 May 2014, Wellington
- 17-19 Jun 2014, Auckland
- 30 Jul – 1 Aug 2014, Wellington
- 15-17 Sep 2014, Auckland“So young Bilbo, will you join us?”… find out more and register to start your journey