Why should the enterprise migrate to IPv6 and what impact will it have?

IPv6 is essential to the continued growth of the internet, due to its vastly expanded addressing space.

Early adoption sectors include markets with strong growth in residential broadband, such as India and China, cable TV providers looking to deliver IP entertainment content to the home and mobile operators growing their population of IP end points, such as smartphones.

Between them, these environments require hundreds of millions of new IP addresses that are simply not available in IPv4, forcing providers to use IPv6.

To successfully communicate with these IPv6-only end points, organisations should be planning to IPv6-enable their public internet presence in the 2012-2014 timescale.

However, organisations should hold back from migrating their internal networks, as most organisations use private IP addressing internally and are therefore not facing any address shortages and the risks and costs of migration to IPv6 are substantial.

Is the migration to IPv6 as straightforward as vendors claim?

Migration to IPv6 is not a simple process at all. It is a completely new protocol that touches not only the network, but operating systems, IT security models and even applications.

An IPv6 project therefore needs to be a cross-disciplinary IT initiative involving all parts of IT in a closely synchronised programme. In some cases, especially with older software, the IPv6 status may be unknown and testing may be necessary to see if the item has its own network protocol stack or is "well behaved" only using the protocol stack in the operating system.

Therefore the scale of the transformation effort is difficult to determine in advance. In these respects IPv6 migration resembles the year 2000 initiative, but without a global deadline. Operating systems and supporting services such as directories will probably need to be upgraded to the latest versions.

Even when products and services claim IPv6 compliance there will often be feature and/or performance differences between IPv4 support and IPv6 support that must be taken into account.

Is there a downside to migration?

There are several issues for organisations wishing to migrate to IPv6. Due to its larger header size IPv6 consumes more bandwidth to deliver the same useful payload than IPv4. This will depend on packet size but for a typical business can easily amount to a 10 per cent increase in LAN and, more importantly, WAN capacity.

For most applications, IPv6 will also consume more processor capacity to deliver the same workload. While this impact varies enormously from application to application, a 10 per cent increase in process capacity used is average. While this is unlikely to be noticeable on client PCs it can be very noticeable on servers.

Gartner estimates that a full transformation to IPv6 in organisations would consume about seven per cent of the total IT budget of the business during the year of transformation and one per cent of the total IT budget for several years thereafter.

Finally, IPv6 security is very immature, as there has been little IPv6 deployment and therefore few efforts to attack it. As with any new protocol, once it is widely deployed it will attract the attention of those wishing to compromise it.

In the labs, vulnerabilities have already been found in IPv6 implementations that were not present in the same vendors' IPv4 implementations.

Many of these challenges will reduce over time, as IPv6 security becomes "battle hardened", drivers are tuned to improve performance and we all deploy newer and therefore IPv6-capable versions of hardware and software.

However, we believe this all argues for an approach of minimum deployment, which in the short term means focusing on the essential task of IPv6 enabling of the organisation's web presence, but the active discouragement of more widespread IPv6 use within the organisation.

Neil Rickard, research vice president, Gartner

How do you monitor the funding of an agile development?

All organisations in the public or private sectors are faced with the constant dilemma of a finite pot of money and seemingly infinite ways to spend it. It's a balancing act of competing demands for capital to support tactical and strategic projects, and programmes in an ever-changing landscape. So it comes as no surprise that fiscal oversight and cost control is a major concern of CIOs and business as agile goes mainstream.

Normally, the key concern is the allocation of capital to what is often perceived as an ill-defined set of requirements and scope. This can lead to organisations adopting waterfall practices for project initiation and funding sign-off, with the intention of delivering the remainder of the project using agile practices. This model may satisfy the funding committee, but often results in wasted effort and time developing a large requirement document that is not necessary.

A more practical approach is to define a high-level view of the project based on story epics (a major scenario that represents a set of users’ stories)  or minimal marketable features (MMF) sets; these then become the project "rails." Funding is based on the understanding that the project will run on the agreed "rails" without major deviation. This still leaves room for change, but if we agreed to build a car and suddenly asked to add wings and a jet engine, we would clearly be off the rails and dealing with serious scope-creep – even beyond agile's flexibility. The epic or MMF approach also has the benefit that it supports the stage gate funding model. Successful delivery of major sets of features forms part of the "go" or "no go" decision to release funds for the next batch of iterations.

This approach can be extended to self-funding or seed-funding projects. In the same way a venture capitalist (VC) may fund a company to get it off the ground, agile seed funding covers the initial iterations to an agreed point where we expect to see a return from the delivered features. At this point a percentage of the project's realised benefits are siphoned off to fund the next phase. This is only really feasible where the benefits are tangible. This has a profound effect on how we fund IT projects. Instead of placing all the risk on one or two projects within the portfolio we can "seed" a mix of high- and low-risk projects and let them grow or wither based on their success. But self-funding and seed funding are not for the faint hearted; after all, they follow a VC model.

How do you manage and monitor the costs to the organisation?

Ongoing cost control of an agile project normally means tracking story-development effort at the task level, just as you track tasks in a non-agile project. The major difference is that agile's short cycles provide a more accurate picture of what is really going in the project and how the money is being spent. By capturing task effort associated with completed stories, we can start to correlate story points with cost. Burndown charts can be annotated with the loaded cost of completed user stories (remember a story is either done or not done, nothing in between). Having developed a correlation with story points and delivery cost we are better placed to forecast the cost of delivering the remaining backlog at any given time. Remember that story points are a relative measure of size, so you have to normalise story points when dealing with multiple teams.

More-formal tracking methods such as earned value management (EVM) have been adapted for agile. Agile EVM has the benefits of being able to measure actual earned value (EV) as opposed to estimated EV which is the case with EVM and waterfall projects.

There is an increasing number of agile-project tracking tools, such as VersionOne, Rally Software ThoughWorks Studio, Parasoft, Agile-Team, to name a few, and the list of traditional project management tools that now have agile support is growing.

Up to now we have focused on funding projects but we must also consider a delivery model for products. Product funding is open-ended; it's a commitment to a solution, provided the solution has business value. Products still have the same fiscal oversight, and feature benefits vs. feature delivery cost have to be monitored just like projects.
Effective agile development depends on effectively monitoring changes in the business environment. What processes and methods should companies put in place to effectively monitor dynamic changes? How do you know if you are getting it right?

Agile development is a closed feedback-loop system, and the single most important part of that loop is business feedback. To formalise this we can use John Boyd's Observe, Orient, Decide and Act Loop (OODAL) cycle, below:

Observations is the most critical stage for agile regarding sensing external and internal change. External influences include shifts in market trends, competitors' new products or new government legislation, while internal influences include the drive to decrease operational cost, integration following mergers and acquisitions, etc.

Line of business (LoB) and process owners have responsibility for making sure they are aligned with corporate strategy. They also have the responsibility of communicating changes in strategy to product owners. Unfortunately, many product owners are not part of the wide management loop and fail to spot shifts in direction. The worst case is where the team is using a product proxy such an IT-based business analyst and LoB may not even have these individuals on their radar and hence strategy changes are not communicated.

Agile teams need to make sure their product owner is keyed in to the wider organisation. Don't assume just because the product owner has the pulse of their user community that they are in the business loop.

Finally, as agile development is a closed feedback system the very act of feature delivery changes the environment that spawned the initial requirements. User Experience (UX) engineering is a critical part observing the internal change.

How do you decide which projects are suited to agile development and which projects are not?

When selecting a project for agile I always ask the following:

1.    Is there a business driver to use agile – time to market, risk of change etc.
2.    Is there active senior sponsorship to use agile on the project?
3.    Will the business stay the course? The No. 1 fail mode for agile is business walking away.
4.    Is the organisation culture a good fit for agile and, if not, can we change it?
5.    Will we have a strong and committed product owner?
6.    Do the teams have or can we train them on the agile principles and practices?

There is a saying in the aerospace industry: "We could make a toaster fly if we wanted to." With agile, we have made the toaster fly. All those verticals and domains that said agile would not work for them have one by one adopted agile in some shape or form. Medical devices, defence, regulated environments, SAP, real-time systems (yes, there is an agile system engineering community) are all tough domains and all have successful examples of agile development. It's not a question of whether agile suits some domains rather than others; it's a question of how much you are willing to change to make the toaster fly!

However, we need to take some caution. Agile is not a silver bullet to all development problems. It is one tool in the tool box. We need to use agile where we are playing to its strengths, such as in projects or products that have a mid to high degree of requirement uncertainty like research and development, innovation, developing new revenue streams. and areas where time to market is critical.

Yet, speed and flexibility are not the only reasons to use agile. Many government agencies are adopting agile after disastrous experiences with big bang delivery. For them, the drivers are greater user involvement, a more-interactive supplier process and minimised surprises (the "How much?!" effect).

Areas where change is not an issue, the domain is well understood and time to market is not a driver can realistically still use waterfall. Waterfall will be with us for a very long time, and when used correctly it works. We must also not forget that traditional iterative methods fill the gap between waterfall and agile and suite projects that require more guidance or do not need to "make the toaster fly."


David Norton is a research director at Gartner.
 

Our service gives readers the opportunity to put their real-life IT questions to the experts from Gartner.

Do you have a business IT question to ask Gartner analysts? Simply post it as a comment on this blog, or email us at feedback@computing.co.uk and we will select the best questions to put to Gartner.

Reader question: We have opted for an SOA strategy for application development, but I don't quite understand what is the relationship between SOA and enterprise architecture?

Brian Burke, research vice president at Gartner, says:

The decision to move to a service-oriented architecture (SOA) strategy must be made within the context of the organisation, not a project or a development team. So, when you "opted for an SOA strategy for application development," you (hopefully) had already made an enterprise architecture decision. If the decision to move to an SOA was made within the narrow context of a project or development approach, there is a high probability of failure. Besides the decision to move to an SOA approach, there are a number of other intersection points between SOA and EA to consider.

Typically, the selection of technologies to support SOA is an enterprise architecture decision. There are many participants in technology selection decisions, including representatives from application development, security, operations and other groups, but enterprise architects will drive technology selection decisions.

Enterprise architects also play a role in determining which services to develop and the development priorities. Enterprise architects typically have a good understanding of the broad application landscape and are well positioned to identify services with the greatest potential for reuse. Enterprise architects (particularly business architects) also know which business processes are highly volatile and can focus SOA efforts to support those processes that must be rapidly reconfigured as business processes change. Enterprise architects (particularly information architects) also have a good understanding of the data that is most commonly used and shared across the organisations. Information architects are well positioned to identify data-centric types of services, which provide consistent access to shared data.

It is a common mistake for organisations to believe that the move to an SOA development approach is purely a development decision. The move to an SOA approach has a broad impact on many areas of the business and IT. Gartner recommends that organisations create an integration competency centre (ICC) as a forum for decision making to support the migration to an SOA approach. Enterprise architects play a key role in the ICC, providing information on the business vision and strategy, guiding principles, future state models and roadmaps, technology standards, and executive sponsorship. 

Do you have a business IT question to ask Gartner analysts? Simply post it as a comment on this blog, or email us at feedback@computing.co.uk and we will select the best questions to put to Gartner.