Showing posts with label futures. Show all posts
Showing posts with label futures. Show all posts

10 June 2012

The Changing Role of the Technology Leader


Infoworld has recently taken a view at How will the CIO's role change by 2020 which was followed up with discussion on linkedin.  I found the article more focused on taking a guess at changing technologies more than changing roles so I decided to take a crack at how I see the role and related skills changing (or staying the same) over the next 5 or so years for technology leaders (CIOs, CTOs, et al):

1. Technical innovation skills.  For companies where technology doesn't enable them to differentiate or compete in the marketplace (that is, no technology development just technology enablement), the technology role will be less critical and demoted to a lower position in the organisation and led by a more operational tech leader.  In companies where technology is developed in a unique way to compete and create value, the role should stay at an executive level and require more innovation and advanced business skills.  Technology innovation leaders will need to know how to speed up rate of change, decrease the costs resulting from rapidly changing requirements and how to scale.  Separation of innovation vs non-innovation business types and resulting change of roles underway now and continuing for the next few years.

2. General technical skills vs other business skills.  Technology leaders aren't business leaders, P&L owners or product managers, otherwise they would be in one of those roles.  They are at the leadership table to be the experts on how technology can delight customers and enable and grow the business.  They fulfil P&L owner aspirations and create highly functional fulfilment envelopes around product and service owners.  This is no different than the HR or Finance leaders, each experts in their area servicing the needs of business line owners.  Similarly tech leaders need to be business savvy and communicate effectively by translating technology concerns to and from business ones.  No change other than non-tech leaders are becoming more knowledgable about tech resulting in increasing communications fidelity of tech concerns in the future.

3. Technical understanding of data security. Due to technical complexity, the technical leader will have to increasingly expand their knowledge of cybersecurity.  They will need the business acumen to strike a competitive commercial balance between flexibility and cost versus risk.  This means increasing knowledge requirements on the technical security side to effectively manage related staff and vendors balanced with sufficient knowledge on the commercial side to collaboratively determine an appropriate commercial balance.  Increasing rapidly the last few years and will continue to do so for some years.

4. Technical understanding of regulatory, legal and compliance requirements.  As nations increasingly understand and depend on the Internet there will be changes in regulations and taxation on Internet activity and supporting infrastructure.  Changes will continue to come from government, banking and infrastructure providers.  This is an area of risk management typically at board level and the technology leader must not get caught out by the changes.  Gradual changes on-going for last 10 years and will continue with occasional "surprise" activity spikes.

5. Ability to identify and remove non-core business and technical activity.  Business process analysis, service delivery, remote staff management and change management are assumed technical leadership skill sets.  Similarly outsource/offshore skills should already be standard for cost reduction and scaling access to talent.  These will increasingly combine in the future to remove non-core processes, products, and services from the business - not just for IT but across the business.  Crowd-sourcing and flexible staffing models will expand.  Changing rapidly for the last few years and will continue for some years.

6. Understand the management of a highly distributed and integrated solution.  Technology delivery continues to fragment requiring increasing expertise at sourcing, integration, and service delivery.  The technical leader must orchestrate different suppliers, a growing number of which are outside of the company and the technology leader's direct control through commercial/contractual expertise and building deep relationships.  Continuing to increase and fragment over time.

7. Budgeting in an opex world.  The technology leader will need to understand how pay-as-you go cloud models and how to transform an organisation dependant on capitalised project thinking into an opex oriented one.  Just starting to change and will accelerate rapidly for next few years.

8. Management of legacy systems and data sets.  The "cruft" of legacy systems and data repositories along with data retention driven by regulatory requirements continues to to expand cost inertia around the technology leader's responsibilities.  Hooking costs to business owners will help.  Knowledge of rapid legacy virtualisation, tiered storage technologies, and integration "envelope" architectural approaches will be required.  Long time problem and will rapidly worsen until better solutions and special-purpose outsource providers come into play in a few years.

9. Understanding of data architecture, access and reporting.  IT has become increasingly effective at monitoring and reporting on technology concerns, including monitoring of customer related data, and is seeing benefit to converging the data into a single reporting system.  Similarly the business has opted for separate and expensive reporting, dashboarding and bolt-on analytics further fragmenting the data.  Further compounding the challenge are cloud/SaaS solutions being sold "around" IT which will eventually need to be integrated and virtually consolidated using data aggregation.  Technology leaders will need to understand the organisation of data, it's benefits and how to make it pervasively and transparently available and what tools and data sets to converge on to enable the business to have a more consistent view of business results and customer activity. Many fragmented efforts underway now from different directions consolidating in the longer term.

10. Understanding and encouraging the use of collaboration tools that cross organisational and corporate boundaries.  As less technical staff learn to use collaboration tools technologists have been using for a long time, they will also increasingly access sources of outside information and informal networks to better compete in a global labor market.  Corporate borders will become increasingly porous and if managed well this proliferation of "commodity" information can be used to drive non-core activity out of the business. Becoming increasingly common and with usage increasing rapidly over the next few years.

The fundamental responsibilities of a technology leader such as people management, budgets, strategy, operations, and development all remain.  However, how most of them are done will see significant changes in the future.

21 March 2010

QCon London 2010 - Miscellaneous Topics

There were no shortage of interesting topics at QCon London 2010.  Although I'm writing in some depth about a few of them due to personal interest and/or applicability to Internet gambling, there are many others I'll highlight here briefly.

Shared nothing architecture
- Each node of a system is stand-alone and shares nothing with other nodes
- Great horizontal scalability
- Shared databases, data stores, caches are constraining
- Great for stateless, single-shot request-response, and content oriented services; less so for multi-state transactional systems

Industry Consolidation driving big boys architectures
- Internet traits such as the network effect and rapid feedback loops accelerate consolidation on a single market-dominant (defacto monopoly) services (e.g., ebay, betfair)
- Big consolidated services require a big compute capacity.  Market convergence on a single supplier isn't possible if that supplier can't scale to meet demand.
- Big compute capacity requires a lot more thought on the "-ilities" (non-functional attributes) of service delivery.  Functionality becomes commodity.
- Web technologies are embracing "traditional" approaches to increase compute capacity: asynchronous message oriented design, greater attention to maximizing hardware
- Consolidation also means longer life of legacy software
- The CAP theorem (see below) is coming into play for big systems that want to be highly available and need to massively scale

Programmer Quality of Life wins over Abstraction and Separation
- XML is painful
- Co-locate configuration with code (annotations)
- Convention over configuration (even Java coming on board with apps like Roo on Spring)
- Repetitive coding requirements should be built in (no boilerplate or scaffolding) - aspects relatively for free
- (Where does that leave dependency specification?  Hello maven pom.xml my nemesis!)

HTML 5, CSS 3, and Javascript versus rich client interface technologies
- Native executables (Wintel binaries) used to be way ahead of the browser on usability and richness but HTML/CSS/JS continues to move the browser experience closer to native executable experience
- Major new browser advances are right around the corner
- Flash, Air, Silverlight - great interfaces but browser continues to advance
- Mobile causing a renaissance of RIA and native executables - but browser continues to advance
- Innovation areas will tend to use an RIA and then the browser will catch up
- High touch experience (e.g., game graphics with high performance requirements) will require native executable performance for some time to come
- For most enterprise and business requirements, the browser experience is already sufficient today

Power efficiency, carbon credits and trading
- Assuming carbon trading advances, we might see a day where well written (more efficient, less energy consumptive) applications are important again
- Energy efficient HW (e.g., Sparc v Intel) may be more valued
- Some odd things may happen such as shifting compute capacity (carbon emission) to third world "carbon dumping grounds" due to economic incentives

Right tool for the right job versus efficiency from limited technology choices
- Although Java is dominant in the enterprise, Ruby is making inroads.  Recognition of productivity boost of a pleasant coding environment that encourages DRY and good programming techniques.
- Functional languages that facilite multi-core (parallel) computing are increasing in popularity as currently popular languages in the enterprise do not (Java!)
- Advent of language neutral information passing protocols to better enable innovation within components (but not forcing between components)
- As of today, homogeneous technology choices for the enterprise are still winning

Software Developer can "do it all"
- Moving test into development through TDD (and from unit to functional and some end-to-end)
- Cloud services abstracting operational systems (the specific HW and OS don't matter)
- Moving live deployment into development (Continuous Integration leading to Continuous Deployment)
- Better to use a shared nothing architecture under developer's control than reliance on specialty approaches like a cache in BigIP F5s or a shared in-memory cache

And a grab bag of others:
  • OSGi and Java.  JARs lack versioning and dependency declarations and therefore lack safe coupling.  OSGi defines bundles to make integration/upgrade safer.  Feels complicated versus using a Convention over Configuration approach.  Could we use co-located annotations in the code instead to describe dependencies?  What about dependencies outside a specific application/JVM?
  • SOA (Service Oriented Architecture) is dead, long live SOA!  (No one seems to like SOA but a lot of practices from SOA are in prevalent and growing use)
  • TDD (Test Driven Development) is pretty much assumed now even for the smallest teams and projects.  CI in varying states but clearly the next development practice that will be an assumption shortly
  • Log everything (Google, Facebook) - both customer actions and internal systems and be able to compare anything to anything
  • CPU clocks hitting speed limits.  Until some new as yet unidentified technology breakthrough, CPU clock speeds have hit about as fast as they're going to be.  From now forward it will be about parallel processing on a growing number of cores.
  • DDD (Domain Driven Design) - Design software with the interests of specific stakeholder's interests at heart, using the stakeholder's terms ("Ubiquitous Language") Let stakeholder interest area ("Bounded Context") warp a "perfect" implementation to one that is tailored to the stakeholder's needs.  In a complex system, identify the Domains of interest, and design around each of them in parallel with figuring out how to glue together these Domains.
  • CAP theorem - pick 2: Consistency, Availability, and Partition tolerance (CAP).  Business will generally pick Availability and Partition tolerance, so that leaves Consistency as the odd man out and implies that more attention is then needed on identifying and recovering from inconsistent states.  Eventual consistency for some functions is sufficient.
  • New persistance models - Social networks with their many-to-many relationships in the data are driving the use of new persistance models to supplement their relational databases
  • Dreyfus model of skill acquisition - a good way to take a view on how people pick up skills and as a way to assess how skilled/mature your staff actually is

17 March 2010

QCon London 2010 - Themes and Trends

Last week I had the good fortune to attend QCon London which bills itself as an "enterprise software development conference".

I thought the conference struck a good balance between maybe 40% academic/futures/ideas from the ivory towers versus 60% practical, grunty software development from the trenches.  That of course varied by what sessions you attended as there were various tracks and tutorials available.

QCon was fairly software development centric.  Although there were tracks on technical operations and QA, both felt more like "what software development thinks how techops and QA should work" versus hardcore QA and techops experts running the tracks and presenting.

Although billed as "enterprise" software development, QCon was new media centric.  Less about enterprise and more about entrepreneurship using (recently) new tools and techniques to deliver and manage software.  I found this quite suitable for igaming that is still more entrepreneur land than it is enterprise.

The following are themes and trends that were in the air at Qcon that captured my interest.  Some will be old and familiar (yet receiving continued attention), others are relatively emergent in the last year or so.  Each item may eventually lead to a blog entry with detailed commentary on the subject and as relevant a view on how they apply to internet gambling systems.
  • Cloud Computing
  • NoSQL versus Relational Databases
  • RESTful architecture
  • Functional programming languages
  • Post Scrum
  • Mobile Computing
  • Event based architectures, asynchronous messaging
  • DevOps, particularly Continuous Deployment
  • Miscellaneous topics