DevOps and Organizational Culture

In the Micro Focus blog series on DevOps, Derek Britton looked the bottlenecks of low collaboration, inefficient development and lengthy testing cycles and how they can be overcome with a pragmatic, technological solution. Here, he turns his attention to that most indiscernible of obstacles: corporate culture.

Letting it breathe

In the Micro Focus blog series on DevOps, I looked the bottlenecks of low collaboration, inefficient development and lengthy testing cycles and how a pragmatic technological solution can overcome them. Here my attention turns to that most indiscernible of obstacles: corporate culture.

Introduction

It has been said that 2016 could be the year DevOps came of age. It continues to gain mindshare including large enterprise accounts. Gartner projects a quarter of the Global 2,000 will have adopted DevOps this year, growing by 21%. Reflecting growing popularity, SHARE in March 2016 has its own DevOps track: “DevOps in the Enterprise”. SHARE has also added a DevOps discussion to its “EXECUforum” agenda, entitled “DevOps: Cultural Mindset”. (We are delighted to join luminaries from IBM, Compuware and CA on the panel).

Share_Event_SanAntonio_social01big

DevOps, as the name suggests, is a technical approach to a necessary business change, namely building new services faster for the business. Put another way, DevOps is a process change, a means to an end. Changing to embrace DevOps affects a number of disparate organizational elements, from IT groups to business, user and customer communities. Clearly, there are important cultural questions in terms of how the organization is ready to embrace DevOps. Culture is widely recognized as being at least as important as strategy. As one report observed, “Changing the culture and mind-set of people is not easy.”

Cultural Barriers to Adoption

Adopting DevOps may flounder for a variety of cultural reasons.

Why are we doing this? While establishing an agile-based methodology in the IT organization makes a lot of sense and, according to history, yielded impressive early results, the parent organization may often be ignorant of the new process. In fact, the business may still expect product roadmap milestones to be planned and met on an annualised basis as part of a traditional regimented plan-build-deliver cycle, unaware of the new dynamic. For IT, breaking down Portfolio and Product plans into Epic and then Iterations is -with a group of trained professionals working together –both viable and valuable. However, ensuring such plans are agreed and acted upon by the consumers of the technology (whether internal users or sales/marketing/customer representatives) is much, much harder, especially when the reason for the change is not clear outside IT. So while like-minded technicians might flock towards DevOps, end-users won’t subscribe to what is probably perceived as extra work for them. They just want results, working apps, not more work. They can’t see the benefit of change.

DevOps3

Moving from big to small. DevOps espouses more rapid, incremental deliveries and a tighter feedback cycle to resolve difficulties and achieve customer satisfaction more quickly. That switch requires the shift from large-scale orchestrated deliveries to more frequent, smaller-scale incremental efforts. The change in dynamics mean there will be greater coordination required by more people on a more regular basis, and a certain level of disentanglement of both application sets and job functions. As one observer put it, successful adoption will require teams to “Embrace the Chaos”. But chaotic it will be, and for larger, more-established, more hierarchical organizations, or those who preside over larger (sometimes referred to as monolithic) systems, that chaos will be most keenly felt.

We don’t have the bandwidth. Restricted infrastructure resources, a problem sometimes faced in large organizations with many parallel work streams is another genuine concern. In some organisations, the change from one model to another might just feel too big. One of the most common bottlenecks is the inability to undertake rapid test cycles as part of a process of continuous integration. With autonomous teams and no restrictions on test environments, as DevOps will need, rapid testing sounds viable. However in a more traditional, regimented IT world, where resources are allocated as part of a planned-for, charged-for system, “just running some tests” is not as simple as that. It might take days, if not longer, to commission a test environment and a very real budget to manage.

Cultural Change – Practicality and Transparency

DevOps is a major upheaval, a major change program. Such change programs need to be clearly outlined, understood, and measurable. So how might DevOps promote wider cultural acceptance?

Get Out There. Failure to involve all stakeholders in a major change program will result in inevitable resistance. Ignorance of why the change is being made will hamper progress. Establishing a clear vision across the organization of why there is a new approach to software deliveries is the fundamental cornerstone of its adoption. To that end, stakeholders need to hear that the reason for the new approach is that the organization is trying to improve the quality of the technology service, and is therefore aiming to deliver more frequently to determine faster feedback, and course-correct. Such a vision is predicated by a top-down C-level sponsorship. After all, the “end game” is new services and customer satisfaction or some other tangible strategic business benefit: DevOps is merely a vehicle to achieve that. Explained this way, especially in the always-on digital age, it is wholly appropriate and acceptable for the supplier to seek to engage more frequently with their users. In a business context in vision, the purpose of DevOps becomes far more tangible and sensible to non-IT stakeholders.

Get Amongst IT. Similarly, for teams responsible for delivering software, from the development, QA and operations functions, previous functional silos and hierarchy no longer apply so readily. But transitioning to a team-oriented structure may take time. Some organizations are borrowing ideas from Agile by establishing functional teams which are temporary for the duration of a major release, or epic, etc. Additionally, many IT organizations are driving internal change with the help of a senior DevOps champion. One organization I know has chosen their new CIO specifically because of their DevOps experience and vision.

Build Bridges. There may appear to be no straightforward resolution to incumbent resource availability (be it related to people, hardware or software), and this is where pragmatism and practicality comes to the fore. Previously accepted practices and platforms may not be as fixed as might first appear. There are a variety of technical solutions available to improving development, testing and efficiency of collaboration for mainframe teams. They can realistically achieve far greater frequency and reach a wider variety of users by exploiting new technical solutions. (One example is Micro Focus’ solution, here).

DevOps bandwidth

Conclusion

Larger organizations have every opportunity to embrace DevOps by taking the cultural aspect of change as seriously as the underlying technical and operational approach they are aiming to use. Practical and pragmatic solutions exist to overcome fundamental operational roadblocks; a comprehensive and transparent cultural change program will also be needed to promote widespread adoption. As a recent ComputerWorld headline put it “Culture is Key to DevOps Success”.

Find Micro Focus at booth #525 at SHARE or visit our dedicated DevOps resources if you can’t attend the event in person.

Brand new year – same old problems?

For technology trend-watchers, the New Year has begun in much the same way old one ended.

As the reports of Black Friday and Cyber Monday-prompted site crashes tail off, predictions about upcoming technology trends kick in, and early 2016 looks much like late 2015. So will last year’s failures help us meet new challenges? Let’s take a look…

Peering into my crystal ball, I see virtual reality headsets, Artificial Intelligence, and driverless vehicles leading the charge of new technology into the commercial stream. The headsets are already on Amazon.

Back in the real world, CIOs are pushing ‘must refine digital strategies’ further up the agenda. It’s a long to-do list. Cloud, big data – and the analytics needed to extract anything useful from it – the ‘move to mobile’, online security, virtualisation, hybrid architectures, containers are just seven.

Other organisations will be trying to adapt to new methodologies, such as Agile and DevOps. Meanwhile, everyone wants to be the first to market with their innovations in digital services, even while cutting costs.

Cutting through the hype, three key organisational goals will remain:

  • Maintaining and protecting brand quality
  • Accelerating time to market, either proactively or reactively
  • Improving the user experience – and creating happy customers

Market movers and shakers

Some start-ups will fly – others will stall – while challenger banks continue to invade the finance space. Retailers will focus more on digital channels, next-gen consoles and virtual reality will fuel the gaming explosion. This means five things for CIOs:

  • The nature and ease of access to this technology will take us places we have never been before – and be even more disruptive than ever.
  • Organisations not keeping up with market trends risk being left behind
  • Bringing unreliable products or services to market risks damaging brand reputation
  • Teams must deliver what the business needs, faster than ever
  • Focusing on delivering what the customer demands and not what the IT departments think the customer wants is key

So how can organisations deal with this three-pronged attack? Using better tools to work smarter will certainly help.

Under attack? Get tooled up

Micro Focus solutions can help fix these issues by enabling them to embrace DevOps, boost business agility and reduce time to market. Any one of these elements protects brand reputation. All of them together will certainly enhance it.

Atlas is an Agile requirements solution. It unites technical and operations teams with business analysts on a platform that captures market trends and innovative stakeholder ideas. This joined-up working means organisations can quickly realise the impact of changes on the product in development, enabling Agile teams to get the right product to the business quicker than ever.

Silk is a platform-neutral automated testing suite that tests application functionality, responsiveness, user experience and performance. Whether deploying on multiple mobile devices and browsers, in the Cloud or on desktops, Silk enables test runs to be managed automatically. With full visibility across the testing and development lifecycle, errors are reduced and teams test earlier in the lifecycle and embrace the DevOps ethos.

So, if this is the year that your organisation gets on the front foot and stays ahead of the curve then give your teams the means to be strategic and not reactive. If this is to be the age of AI and next-gen tech, selling products that drives customers to throw themselves in front of the nearest driverless vehicle seems like last year’s thinking.

Whether this is to be a happy New Year or twelve months of challenges is entirely in your hands.

Crawford

Delving into DevOps – the Data

DevOps is on everyone’s lips these days, but we’re not all talking about it in the same way. Derek Britton takes a look at the latest industry study to find if there’s anything we can all agree on

The Customer, DevOps and Micro Focus

Recently, we’ve been speaking frequently with our clients about the popular DevOps topic, and we are hearing more examples of its implementation, usage and success. Lately, we heard of one client who has built a DevOps framework at the centre of their entire IT operation; we have seen another client recruit a new CIO specifically because of his DevOps experience.

… oh, and everyone else

This is indicative of a broader industry appeal around the topic. According to one observer, “we are seeing the gold rush phase for DevOps in 2015[1]”. Consider just a few of the public events around Devops in recent months:

Each of these will no doubt repeat in 2016, joining the Cloud and DevOps World Forum – and that’s not to mention the plethora of vendor-specific events that will showcase their own DevOps angle.

DevOps2

Read all about it

Of course, there’s no need necessarily to travel to learn. Publications on the topic are wide and varied ranging from the highly accessible Mainframe DevOps for Dummies (by IBM luminary Rosalind Radcliffe, as launched at SHARE, August 2015) to the acclaimed and comprehensive Phoenix Project by Gene Kim. Meanwhile, taking that knowledge further presents seemingly limitless possibilities. Devops-related certification, training, press articles and blogs is seemingly limitless, as are the mentions of DevOps as a key element of many a vendor’s messaging today.  (I can’t tell you how many times I have read a vendor promote that they are “The Devops Company”).

Delving into DevOps

Now, while it could be argued that some of the DevOps documentation is slanted according to the perspective of the authors, this is often the case while new trends emerge and attempt to define themselves clearly. Establishing a de-facto “truth” from the various viewpoints is often the task of broader surveys and industry studies. A CA study from 2013 suggested tangible results  and inferred at least some direction on how the industry was embracing the idea. More recently, another global survey was conducted byDevOps.com which may – we anticipate – provide further insight.

A third example of an industry study is the far-reaching and illuminating 2015 Annual State of DevOps: “A global perspective on the evolution of DevOps”, conducted by Gleanster/Delphix.

DevOps4

A Real State

The study surveyed 2,381 IT practitioners or leaders from across the globe, including 49% at CIO or IT Director level.  The appetite and effort towards DevOps adoption was evident in the response – very interestingly 73% of those surveyed had already set up a dedicated DevOps group. Other results include a number of interesting perspectives that Micro Focus shares.

  • When looking at the specific DevOps practice, the results reported that “continuous integration” was the 2nd most popular activity among DevOps leaders, with 64% respondents agreeing to this stated aim. This is consistent with Micro Focus’ view where efficient, repeatable and rapid build and test cycles were a key requirement in DevOps adoption[2].
  • In terms of who drives DevOps – the question was put as bluntly as “Dev or Ops?” The results showed Dev as the senior partner (50%), with Ops at 17%. A “shared” leadership was 34% (one can only assume the numbers were rounded up as they didn’t total 100% exactly). This is consistent with Micro Focus’ assertion that Development often has to act as the “leading light” in DevOps activities.
  • The rationale and motivation for DevOps saw a top 3 in terms of responses listed as Faster delivery (88%), Faster bug detection (69%), and Greater Delivery Frequency (64%). This is consistent with Micro Focus own market view, where the drive towards faster delivery of more predictable, high quality deliveries is a fundamental principle of DevOps adoption. This is especially true for our mainframe clients, where reliability and availability are critical.
  • Finally, a soul-searching question about “how effective at DevOps” each organization was provided some interesting insight. While “leaders” were very upbeat (96% saying they were “very” or “somewhat” effective), those who classed themselves as “practitioners” were less positive, with nearly two-thirds saying they were only “somewhat effective” or “ineffective”. The disparity between leadership and practice is perhaps not atypical, but it indicates or at the very least begs the question that desire may outstrip the reality in many cases.

DevOpsBlog

 

Hope and Hype

The study makes interesting reading. DevOps enjoys growing clarity, purpose and investment, yet faces significant ongoing challenges. Aiming towards faster delivery, higher frequency and better bug detection will improve results and reputation, such that the hope will catch up with the hype.

Fixing such specific challenges in the delivery cycle is the cornerstone of the Micro Focus solution for mainframe DevOps: providing practical solutions to real industry challenges. We look forward to the debate continuing.



[1] Gleanster, Delphix, 2015

[2] Most popular was agile data management

Unified AppDev – DevOps Mainframe Efficiency

While the DevOps methodology appears to promise significant improvements in efficiency, it relies on significant changes to internal practices in environments which are – frankly – quite hard to change. In his third blog in the series Derek Britton explores whether taking a smarter approach to mainframe DevOps might bring the goal of development efficiency within reach

Introduction

‘We’re all about smaller, focused teams, working on manageable sizes of work, with a regular and clean delivery process’. That’s Agile, or Scrum or one of its equivalents, talking. DevOps, to paraphrase, would respond ‘that’s fine, but let’s include the testing  teams as well, so those regular deliveries can stand up to scrutiny over quality, fitness for purpose and  user feedback‘.

Using a focused, multi-skilled team to work together on manageable deliveries and testing the whole delivery as a single unit of work? Well, frankly, it takes courage to argue against it. Anyone doing so would be presumably thinking wistfully of protracted waterfall models with huge projects that never fully sign off the scope and cannot test that volume of changes in the time allotted, where precious skilled resources are pulled from pillar to post to rectify unplanned issues. Leaving that all behind is certainly a good strategy. But how does that stack up for the mainframe environment?

Regular and Clean Delivery Process?

These are where the problems could start.

Of course, the mainframe processes are regimented and rule-based, yes, orchestrated and established, certainly.

But the frequency of delivery is based on the payload, other priorities, resource availability, and often – crucially – mainframe resources too.

And ‘clean’ is slightly subjective perhaps, but there’s nothing simple about the quality of required deliveries. Rudimentary errors such as compile errors aren’t uncovered until the next day. The COBOL team has their part, the Java team another – and what about the middleware? Even straightforward debugging or basic unit testing requires QA to be on stand-by to help set up the environment, as well as sys-admin.

So, clean? A little tainted, maybe. One Micro Focus customer faced an application change reality – not uncommon in the mainframe world – where regular challenges faced the beleaguered development team and application development cycles were slow compared to other language teams [though the mainframe applications were where the business value resided]. The cause was diagnosed as a combination of cumbersome tooling and restrictions in available mainframe processing time.

Delivering applications composed of mainframe COBOL and distributed Java assets was becoming more regular, and therefore more critical, yet the teams involved were split by structure, process and technology usage. Collaboration over bug fixing, unit testing and QA was extremely difficult.

The Solution – AppDev Sans Frontiers

The solution was as dramatic as it was straightforward. A single, unifying toolset, as modern as it needed but mindful of more established technology.

DevOps Blog 3 image 1Figure 1 Smart z/OS development with Enterprise Developer

Micro Focus’ IBM mainframe application delivery suite flagship – Micro Focus Enterprise Developer (figure 1) – enabled the teams to use a common development toolset, independent of scarce mainframe resources. The powerful Eclipse-based IDE provided freedom for mainframe developers to work in isolation when necessary, but also share source code and other application resources as a group, without burdening the busy mainframe.

To summarise the net benefits for this particular customer – and many other current Micro Focus users:

  • Composite core applications can be developed, debugged and unit tested using a single development environment
  • COBOL and Java application developers can collaborate and interact at a development level, using the same environment

All application developers, including mainframe COBOL developers, can achieve improved levels of efficiency, through access to contemporary development tooling. Over 25% efficiency improvements are possible.

DevOps Blog 3 Image 2Figure 2 – Side by side COBOL and Java development, courtesy of Micro Focus

Figure 2 illustrates how Micro Focus technology literally provides side-by-side development for both COBOL and Java application assets from within the same Eclipse IDE.

Additionally, customers looking to unite COBOL and Java, for example, can utilise Enterprise Test Server as a basis for composite application testing, without imposing further on mainframe resources – perfect for integration and functional testing.

A timeless, ageless solution

Furthermore, many customers are also grappling with questions over future resourcing. After all, these COBOL systems have outlasted any reasonable prediction of their life-span, such is the robust and enduring value of both the applications and the underlying technology. Micro Focus’ development tools helps with this – it is a smooth introduction to a more efficient development model for mainframers, but it is also a perfect training ground into the mainframe world (and the COBOL language) for the younger developers with no such background.

In a recent article, a 19-year-old intern at a technology company described a two-hour learning process during which they learnt how to code in COBOL, using a contemporary IDE and had built their first application. In our client scenario, the results were astounding – skills are now no longer a concern, as the average age of the mainframe developer for this client has been reduced to 26.

Unity is Strength

The Micro Focus environment now acts as the basis for all core application development work in that organization; such has been the far-reaching benefits to the technical teams in meeting efficiency targets. So whether the application development requirements are directly connected to the mainframe, fully offloaded, or whether the language requirements are COBOL, Java, PL/I or a mixture, there is a unified development framework for all.

The phrases ‘shorter development cycle’ and ‘increased release velocity’ are often cited as the major outcomes of adopting DevOps. One measurement the client shared was that, thanks to reduced mainframe dependency and improved tooling; a full core system compilation task has been reduced from a full day on the mainframe to 23 minutes under Enterprise Developer.

Find Out More…

Better development efficiency through modern tooling and collaboration is not the only DevOps objective. But this was a major issue with this client. And their goal was improved efficiency to provide better services, faster to their clients.

Micro Focus technology acted as a platform for improvements in working practices to enable a step change in efficiency, based on central DevOps principle of collaborative development. Visit us to learn how Micro Focus can assist your DevOps adoption and resolve your mainframe skills questions.

In our next and final blog of this series I will take a look at the DevOps challenge of testing efficiencies, in the context of mainframe application delivery.

DevOps – a culture of collaboration

DevOps is a software development methodology which promises greater efficiency and throughput of change through transparency, collaboration and flexibility. But it depends on significant changes to internal practices for many. In the second of our Mainframe DevOps series, Derek Britton opens up the discussion on a key DevOps principle: a culture of collaboration.

Introduction

The Agile manifesto suggests good practice for building software is to establish manageable iterations in which smaller chunks of work are taken, worked on and delivered in smaller timeframes by a dedicated team. DevOps seeks to add further discipline and flexibility by driving a more focused and inclusive process across IT.

We need to talk about IT

Fundamentally, DevOps aims to provide a sensible transparent point of intersection between the disciplines of Development, QA/Testing and Operations. This espouses (and largely depends upon) collaboration, flexibility and – ultimately – internal operational efficiency.

But is that really possible in a mainframe environment? Industry evidence talks about two thirds of all development shops being aware of DevOps, but that doesn’t mean they are aligned or structured – or even inclined – to collaborate.

CIOz13

Teams and Tools

In one particular client situation, a major application set was the centre of a significant industrialised development process to service several lines of business from the same source code. However, both in terms of team structure and tooling (development, testing, configuration management), there were significant restrictions in terms of the level of flexibility and parallel activity, meaning the line of business deliveries needed to be managed in sequence rather than

Failure to collaborate and adopt modern development methods was, in effect, jeopardizing business efficiency. The client needed flexible and more frequent releases to accommodate a range of unrelated application changes, and sought a model for parallel development across features, releases, or teams to achieve this.

A Contemporary Approach

While there was going to be some change in working practices, adopting modern tooling was the nucleus of the solution.

The flagship of our IBM mainframe application delivery suite – Micro Focus Enterprise Developer – enabled the teams to use a common development toolset which was not dependent on scarce mainframe resources. The powerful Eclipse-based IDE provided freedom for mainframe developers to work in isolation when necessary, but also share source code and other application resources as a group, without burdening the busy mainframe.

At the same time the team adopted a distributed SCM tool (in this case Micro Focus AccuRev) in order to provide a secure, multi-user approach to source code management for the earlier phases of the development and testing cycle. Integrating with their mainframe based SCM later in the delivery cycle maintained the integrity of their promotional model while building in greater flexibility at the early development stages.

A New Chapter

The client has embarked on a new chapter where its traditional mainframe development practices have evolved, without undergoing any risky seismic overhaul, to support contemporary practices. They’ve done this simply because that’s what the business needed.

The upshot is that a greater number of IT delivery projects are running concurrently, delivering more functionality to the business in less time. Improved tooling and visibility also means less time spent fixing regressions or backing out changes.

The phrases ‘Shorter development cycle’ and ‘Increased release velocity’ are often cited as the major outcomes of a DevOps model. While by no means a full-blown DevOps shop, it is already benefitting from one DevOps’ fundamental tenets.

Want A World View? – You Need an Atlas

Another potentially vital consideration is the flexibility with which the workload can be prioritize and shaped in the process. We’ve spoken so far about improving the production process of building and delivering in efficient parallel streams. But what about the tasks in the first place. Establishing an equally flexible, transparent method of capturing and managing the tasks. Agile requirements management benefits from a significant recent investment by the Borland team, as covered in the press.

Atlas

Need More?

Improved collaboration and a parallel development model is by no means the full DevOps story. But this was the major issue with this client. And their goal was improved efficiency. Micro Focus technology acted as a platform for improvements in working practices to enable a step change in efficiency, based on central DevOps principle of collaborative development. We’ll look in our next blogs at improving development and testing efficiencies. You might also like to read my introductory DevOps blog post here.

We are asked a lot about how to build greater efficiency into core systems delivery. We spend a lot of time in the #DevDay agenda talking about precisely that. Why not come to an event near you soon where you can see for yourself what’s possible?

The Development Manager’s conundrum: Do even more, with less. Faster

iStock_000015940814Small

Sound familiar? We’ve heard this from so many of our customers. They are trying to tackle the seemingly impossible – increase innovation to supply customer demand, while maintaining what already exists. To push the boundaries while keeping the lights on. This blog highlights the challenge and suggests an answer. Because we believe that Development Managers responsible for delivering COBOL applications really can do more, with less – and faster.

(For the purpose of this blog, I’m focussing on COBOL applications built on distributed environments such as Windows, Unix and Linux – but if your COBOL applications are on the mainframe, then take a look at this blog[m1] ).

 The Development Manager’s Enigma

COBOL is modern and agile. Discuss. Well, it will be if it can resolve the two fundamental application development challenges that our customers are talking about. They are:

1.      Keeping the lights on

We’re told that the majority of resource is needed just to keep the wheels turning. Maintenance of existing applications is a must, and there is a major backlog to make application improvements.  According to Gartner, the overall cost of ‘IT debt’ is projected to reach $1 trillion by 2015. Forrester cites that 70% of IT budgets are spent on maintenance tasks. Big bucks, big problem.

2.      Delivering innovation

Staying in business is all about keeping up with industry trends. It’s a must. Doing nothing is going backwards. Tech-savvy consumers are forcing the adoption of new technologies such as cloud, mobile and new IT architecture.  If businesses refuse to embrace these technologies, their customers will look elsewhere.  And they won’t be back.

Doing one without the other is not enough. So, the two challenges are essentially one: Keep the lights on and deliver innovation.

It’s your choice

Typically, there are four approaches to addressing these challenges:

1. Do nothing

Carrying on as normal has some merit. No action, no risk. But if you aren’t able to keep up now, then it won’t provide you with the step-change in business agility that you need. Inertia and performance don’t mix.

2. Rewrite

Many customers tell us they consider rewriting their applications in another language. However, this is timely, costly and high risk – with as many as 75%[1] of all rewrite projects failing. Keep looking.

3. Replace

Another favourite is replacement with an off-the-shelf package. It might sound appealing for a quick fix, but what happens to the decades of business intelligence and IP built up in your existing applications? You might lose competitive advantage. Additionally, our experience tells us that approximately 40%[2] of replace projects are cancelled.

4. Revamp

Naturally, this is the option that we advocate in most situations. Revamping means reusing your existing investments – your people, your processes and your existing applications – to create a new, improved environment. Because COBOL is modern and agile, it enables a fresh approach to how you build and deliver. This is the key to addressing the Development Manager’s enigma.

Maintain and innovate

COBOL is modern and agile. Still don’t believe me? Here are a few examples from our customers who have tackled these challenges, and with great results.

Addressing the COBOL skills shortage is one of the first hurdles – development teams often work in siloed development environments, broken down by programming language or the tools they use, which can inhibit application development. Using Visual COBOL, c# programmers at Nationwide Insurance were productive within 1 hour, simply because they were developing COBOL applications in Visual Studio, a modern IDE with which they were familiar. (Visual COBOL can also be developed in Eclipse).

Because traditional COBOL can be developed and maintained in modern environments, development efficiencies are also a key benefit. Using Visual COBOL, OM logistics saw a 30% improvement in efficiency.

These skills and efficiency enhancements mean your team can spend less time fighting the backlog, and more time innovating to supply consumer demand. But how can COBOL help you innovate and embrace disruptive technologies?

Well, because COBOL is modern and agile, you can deploy COBOL applications onto the latest platforms and newest technologies. Here are some great examples where our customers have done just that:

  • The Treasury of the Republic of Cyprus saved €250k per year taking their existing COBOL application to HTML5 to deliver a mobile web application.
  • Acciona Trasmediterranea saved 70% of IT costs and reduced time to market by 25% taking their existing logistics application to the cloud.
  • Zucchetti, a Human Resource application provider embraced modern IT architectures to speed up the adoption of .NET and JVM for COBOL application deployment.

Clearly most innovations are possible – it’s just a matter of finding the skill and resource to be able to deliver them.

Now do you believe me?

So – are you converted? I hope you can see that COBOL is both modern and agile. That it can deliver development efficiencies of up to 30% and reduce time to market by 25%.

What do your COBOL applications do and how could you modernize yours? If you want to learn more, take a look at how many of our customers are already delivering innovative solutions with modern and agile COBOL: www.microfocus.com/cobolcustomers

The Legacy Myth: Legendary IT

Legendary IT

So far in this blog series, we have introduced the question about “legacy” as a term in IT. We’ve spoken about the fallacy that legacy IT is bad. We’ve suggested that legacy should be considered in the positive or should at least be used more appropriately. We’ve heard from clients who have said “this isn’t legacy, this is my core business”. These functioning, valuable, long-standing core systems -far from being undesirable legacy – are “legendary”.

So the question isn’t so much “should we harness our so-called legacy?” The question ought to be, “how should we harness it?”

How have organizations gained more from their existing core systems without falling into the trap of seeing them as being ready for the trash? Let’s take a look at a five stage process of how Micro Focus customers have achieved the very best from the legendary assets they have at their disposal today.

Know IT

Without knowing what your legendary systems are, the value they bring, and what they do, the danger is that the value is not harnessed correctly. Over time, as knowledge of those systems also wastes away, these systems risk moving towards a state of decline brought about through an ignorance of their value.

IT leaders would greatly benefit from factual insights into key components such as cost, value, customer satisfaction, strategic fit, resource requirements, and rates of change, in order to make well-informed business decisions. They need to be prepared to face change in IT systems every day of their working lives, because “change” is the only consistent element in the world of IT.

Innovative smart technology simplifies the process of understanding core systems even if knowledge has been lost. It automatically builds key decision criteria, and allows IT to truly measure the value of what it owns.

Micro Focus helps organizations looking to make complete sense of their application portfolios. We deliver technology to provide a centralized business and technical insight. This allows managers, architects and development staff to acquire the vital wisdom they need to make the right IT decisions for the future.

Develop IT

The Forrester Report stated that, “most of the budget still goes toward ‘keeping the lights on’ as opposed to new business initiatives, while CompTIA’s State of the IT Skills Gap declares, “The dynamic, fast-changing nature of technology and a lack of training resources are the biggest factors contributing to the skills gap”. With such resourcing and technological challenges continuing, IT is faced with mounting pressure to develop applications as quickly as they are being demanded.
Worse still, new architectures and requirements for these systems evolve with each passing year: e.g. .NET, JVM, Mobile and Cloud.

Preserving the functionality of core systems, while embracing new architectures and making them work together, is key.

Eclipse and Visual Studio IDEs support a single application view that enables a user to work with Java, C#, COBOL and other languages, simply by sharing the same development ingredients. This resource flexibility caters for modernized mainframe applications, providing better scaling as business objectives evolve. Micro Focus provides a highly productive environment for building distributed or mainframe applications – which consist of COBOL and other languages – allowing organizations to spend less time on “lights on” work, so they can focus on delivering new business value.

Micro Focus enterprise application development technologies enable developers to build, maintain and enhance core enterprise applications. These ultramodern development tools, running under Visual Studio or Eclipse, enable collaboration and greater developer productivity, as well as enabling the use of other technologies to enhance and support core COBOL applications including Java, C#, WPF, WCF, JavaFX, HTML5, and Silverlight.

Prove IT

Not a week passes without a press article concerning a major IT system failure1. Quality is a cornerstone discipline of IT. But an equally complex challenge in the application lifecycle is the time it takes to deliver new functionality to the business, with the suitable level of quality. The amount of time it takes to run all the testing is shaped by the volume of tests and data. The battle over resources involved in the testing cycle adds to the problem, as does the inherent inefficiencies in the testing process, which in many cases remains manual, error-prone and largely unstructured.

Micro Focus provides a range of technology to assist in the overall improvement of the testing phase in the software delivery cycle.
Firstly, Micro Focus technology can alleviate capacity bottlenecks which occur in the release process, by providing a highly available, scalable, testing environment. In addition, Micro Focus technology can automate and speed up the execution of system and performance testing. Combined, these support dramatically faster delivery cycles, with the assurance that the levels of quality will be better than you could ever have imagined.

Run IT

The total cost of ownership of IT systems is significantly affected by the ongoing operational cost of running the systems in production. Organizations looking for greater flexibility in their operations often scrutinize the production platform.

Micro Focus technology supports a flexible and highly portable deployment environment. This offers organizations genuine choice in deciding on a suitable approach for their application workload deployment.

Micro Focus Enterprise Server enables deployment of enterprise workload to take place where it makes most business sense, while leaving the applications just as they are.

Its sibling product, Micro Focus COBOL Server, makes it possible to deploy enterprise class business-critical distributed applications on the widest range of platforms. Micro Focus’ highly-portable deployment technology architecture means that existing applications can be deployed onto new platforms, including .NET, JVM and the cloud, and the same application code can be deployed across multiple environments, without change.

Improve IT

Even if you make your IT system better than it was yesterday, it might not be good enough tomorrow. IT must continuously improve its systems: to stand still is to move backwards.

Whether IT is waterfall or agile, it will use some form of management and control philosophy. By supporting all key phases of the core system development lifecycle (SDLC), Micro Focus provides productive and cost efficient solutions to all application delivery challenges.

Borland2‘s lifecycle management technology enables improvements to be measured, monitored and achieved, step by step. In providing technology right across the application lifecycle management discipline, Micro Focus ensures that the journey of continuous improvement is a rewarding part of your business plan.

Conclusion

So-called legacy environments are anything but. IBM’s multi-million dollar investment in the ground-breaking zEnterprise mainframe environment and Micro Focus’ continued stewardship of COBOL as the most prevalent business language, demonstrate the on-going commitment to trusted technology.

Let’s just say it: legacy IT is a nonsense term. It is misleading, it creates the wrong impression, and it is usually thrown about by people who don’t actually know the truth about those systems. As Keith Wild, Director of IT at Blue Cross Shield in South Carolina says, “To refer to what we do as legacy in any way is both ignorant and incorrect… What is important is the value it brings to us today”.

In fact, this is clearly not about the age of the technology. Stuart Meyers, Attachmate APAC Product Marketing Manager at The Attachmate Group, commented on LinkedIn, “My iPad 1 is a legacy system that I rely on every day, and now it’s end-of-life, out-of-support and won’t accept the latest OS”3.

A recent IDC publication concludes, “…with such available approaches and a contemporary model into which core COBOL business systems can be transformed, the term “legacy” as it pertains to these systems is no longer accurate. As CIOs who run their business on COBOL have indicated to IDC on more than one occasion, ‘These applications are not legacy; these are my core business.'” 4

Micro Focus has been protecting the value of core IT systems for forty years. The products and solutions offered by Micro Focus have enabled businesses to take their legendary systems into the future, making significant improvements and pointing businesses towards necessary future innovation. The legend lives on…


1 The Royal Bank of Scotland’s mainframe blackout in 2012 was the result from an upgrade to the mainframe batch scheduling system. On New Year’s Eve 2012, Lloyds TSB customers were unable to get any money out of cashpoints or pay by debit card. Credit in customer accounts also appeared to have vanished.
2 Borland.com is a Micro Focus brand.
3 Legacy Modernization Group on Linkedin.com, discussion “Why Legacy has a bad name in IT”. Group membership is subject to approval.

4 “Modern Approaches to Application Modernization” – IDC white paper, Al Hilwa, August 2012.

Putting Software Quality Best Practices to the Test at Better Software West 2012

Software testers are always bombarded with the same earnest “best practices” to help them better perform their jobs – attend quality certification programs, understand the tester’s role in agile development, use the keyword drive approach, etc. Clinton Sprauve, director, product marketing & strategy, Micro Focus, sings a different tune during his session at next week’s Better Software West Conference in Las Vegas.

Clinton will provide alternatives to traditional best practices as they relate to the constantly evolving and complex world of software testing. Join him if you’re in the area on June 14!

Session Details

The Mis-education of Software Testers – Rethinking and Relearning Software Quality

When: Thursday, June 14, 2012, 10:15 AM PDT

Where: Caesar’s Palace, Las Vegas, NV

What: This session will provide alternative perspectives on software testing best practices, such as keyword-driven testing, requirements traceability, the tester’s role in agile development, quality reporting, tool expertise, and quality certification programs.

StarTeam® Goes Agile!

StarTeam’s exciting new agile support promises real benefits for companies looking to bring their agile processes and mainstream delivery closer together.

May 15th 2012 marks the official release in beta of StarTeam’s new agile planning and tracking support, which we are calling simply StarTeam® Agile.  We’ll be reaching out to our StarTeam customers to ask them to get involved in what we believe is an exciting new phase in software delivery.

So, if you are a StarTeam customer, aside from hoping you’ll be as excited about this as we are, we would ask you to look out for the information that’s going to be coming your way shortly after that release date and get in touch with us.

In the meantime, read on for why we honestly do believe this is something you’ll want to be part of…

The rise of agile

Software development organizations of all sizes are turning to agile methods to help them improve their ability to deliver great software.  Quite what form that adoption will take tends to vary, based on factors like size, industry, and geographical distribution, but the general view is that a hybrid approach being called ‘Water-Scrum-Fall’ is emerging as the most common scenario, where traditional requirements gathering feeds an agile development phase, before handing off for final acceptance testing.

But whatever the detailed implementation of ‘agile’, it’s generally agreed that software delivery organizations are looking to make it a bigger part of their process.  And why wouldn’t they?  Agile brings collaboration and better stakeholder involvement, which in turn brings faster decision-making, better developer responsiveness and improved time to market.

All of which, of course, tends to bring happier customers.

The challenges of agile adoption

But the adoption of ‘agile’, especially in larger organizations, is not without its challenges.  Integrating agile practices or teams with existing, more traditional processes can prove frustrating for both developers and managers; the objectives, and indeed the overall philosophy, of each party often seem to stand in complete contradiction to the other.  On the one hand, the need for high-level aggregated information drives a desire for data collection, dashboards, and unification across all delivery processes, regardless of method or underlying technology.  On the other hand, the emphasis is on co-located teams and manual processes, on working software and lightweight tooling.

And it doesn’t stop there.

As well as needing management visibility for the purposes of planning and tracking, the question of corporate governance has the potential to strain relationships too, with talk of the need for traceability, workflows and audit trails raising the hackles on many an agile practitioner’s neck.

The power of StarTeam

This kind of visibility and control has always been within the reach of StarTeam users, with the robust change management platform taking things way beyond source control, to provide much-needed insight across the entire lifecycle.

The 12.0 release of StarTeam took things a stage further, enabling users to define their own asset types (through the use of ‘custom components’) and bring in more third-party data (through the use of the Tasktop Connector for Borland).  This now means that many more assets can be tracked, with defects from Jira or Bugzilla, for example, appearing alongside requirements from HP or StarTeam, as well as any other custom assets needed to support the software delivery process.

It is fair to say, though, that supporting agile teams in StarTeam has not been without its own set of challenges, either requiring StarTeam users to bend their way of working to fit the tool, or necessitating the introduction of additional functionality through the powerful StarTeam SDK.

This is no longer the case.

Real agile support comes to StarTeam

Agile teams can now work in a natural, even tactile way, recreating many of their preferred manual activities, without having to concern themselves with any of the underlying architecture – while at the same time, all their assets and all their changes, like user stories and tasks, are being tracked, traced and versioned, helping to build a comprehensive view across the entire project landscape, regardless of methodology or geographical location.

And as well as supporting the needs of the agile teams, some of the more specific benefits coming through the power of StarTeam include:

  • Seamless and automated traceability from agile task to source code.  As soon as you create and assign your agile tasks, they appear in the developer’s task list in their IDE, even without refreshing – and from that point on, as the task is activated and code is edited, traceability is being created.
  • Running agile processes against existing projects, releases and teams.  As soon as StarTeam Agile is installed in your system, it connects to your existing StarTeam server and automatically enables you to see all your existing projects, releases and teams, removing the need for any manual intervention in keeping your agile activities up to date alongside all your other projects.
  • Snapshot the state of your agile assets using the same mechanism that you already use for your code.  All StarTeam users understand that version control is not just about source code; all other software assets are changing too.  Keeping on top of this not only means knowing which version of a requirement or defect links to any given version of source code, but also which release or product build that user story or task got completed in, so your customers can upgrade in full knowledge that their issues or requests have been addressed.

So, if you think this all sounds interesting, please get in touch and look out for more information as it becomes available.  May 15th is the official beta release date for StarTeam customers.

StarTeam® Goes Agile!

StarTeam’s exciting new agile support promises real benefits for companies looking to bring their agile processes and mainstream delivery closer together.

May 15th 2012 marks the official release in beta of StarTeam’s new agile planning and tracking support, which we are calling simply StarTeam® Agile.  We’ll be reaching out to our StarTeam customers to ask them to get involved in what we believe is an exciting new phase in software delivery.

So, if you are a StarTeam customer, aside from hoping you’ll be as excited about this as we are, we would ask you to look out for the information that’s going to be coming your way shortly after that release date and get in touch with us.

In the meantime, read on for why we honestly do believe this is something you’ll want to be part of…

The rise of agile

Software development organizations of all sizes are turning to agile methods to help them improve their ability to deliver great software.  Quite what form that adoption will take tends to vary, based on factors like size, industry, and geographical distribution, but the general view is that a hybrid approach being called ‘Water-Scrum-Fall’ is emerging as the most common scenario, where traditional requirements gathering feeds an agile development phase, before handing off for final acceptance testing.

But whatever the detailed implementation of ‘agile’, it’s generally agreed that software delivery organizations are looking to make it a bigger part of their process.  And why wouldn’t they?  Agile brings collaboration and better stakeholder involvement, which in turn brings faster decision-making, better developer responsiveness and improved time to market.

All of which, of course, tends to bring happier customers.

The challenges of agile adoption

But the adoption of ‘agile’, especially in larger organizations, is not without its challenges.  Integrating agile practices or teams with existing, more traditional processes can prove frustrating for both developers and managers; the objectives, and indeed the overall philosophy, of each party often seem to stand in complete contradiction to the other.  On the one hand, the need for high-level aggregated information drives a desire for data collection, dashboards, and unification across all delivery processes, regardless of method or underlying technology.  On the other hand, the emphasis is on co-located teams and manual processes, on working software and lightweight tooling.

And it doesn’t stop there.

As well as needing management visibility for the purposes of planning and tracking, the question of corporate governance has the potential to strain relationships too, with talk of the need for traceability, workflows and audit trails raising the hackles on many an agile practitioner’s neck.

The power of StarTeam

This kind of visibility and control has always been within the reach of StarTeam users, with the robust change management platform taking things way beyond source control, to provide much-needed insight across the entire lifecycle.

The 12.0 release of StarTeam took things a stage further, enabling users to define their own asset types (through the use of ‘custom components’) and bring in more third-party data (through the use of the Tasktop Connector for Borland).  This now means that many more assets can be tracked, with defects from Jira or Bugzilla, for example, appearing alongside requirements from HP or StarTeam, as well as any other custom assets needed to support the software delivery process.

It is fair to say, though, that supporting agile teams in StarTeam has not been without its own set of challenges, either requiring StarTeam users to bend their way of working to fit the tool, or necessitating the introduction of additional functionality through the powerful StarTeam SDK.

This is no longer the case.

Real agile support comes to StarTeam

Agile teams can now work in a natural, even tactile way, recreating many of their preferred manual activities, without having to concern themselves with any of the underlying architecture – while at the same time, all their assets and all their changes, like user stories and tasks, are being tracked, traced and versioned, helping to build a comprehensive view across the entire project landscape, regardless of methodology or geographical location.

And as well as supporting the needs of the agile teams, some of the more specific benefits coming through the power of StarTeam include:

  • Seamless and automated traceability from agile task to source code.  As soon as you create and assign your agile tasks, they appear in the developer’s task list in their IDE, even without refreshing – and from that point on, as the task is activated and code is edited, traceability is being created.
  • Running agile processes against existing projects, releases and teams.  As soon as StarTeam Agile is installed in your system, it connects to your existing StarTeam server and automatically enables you to see all your existing projects, releases and teams, removing the need for any manual intervention in keeping your agile activities up to date alongside all your other projects.
  • Snapshot the state of your agile assets using the same mechanism that you already use for your code.  All StarTeam users understand that version control is not just about source code; all other software assets are changing too.  Keeping on top of this not only means knowing which version of a requirement or defect links to any given version of source code, but also which release or product build that user story or task got completed in, so your customers can upgrade in full knowledge that their issues or requests have been addressed.

So, if you think this all sounds interesting, please get in touch and look out for more information as it becomes available.  May 15th is the official beta release date for StarTeam customers.