How DevOps oils the Value Chain

DevOps ? a clipped compound of development and operations – is a way of working whereby software developers are in a team with project beneficiaries. A client centred approach extends the project plan to include the life cycle of the product or service, for which the software is developed.

We can then no longer speak of a software project for say Joe?s Accounting App. The software has no intrinsic value of its own. It follows that the software engineers are building an accounting app product. This is a small, crucially important distinction, because they are no longer in a silo with different business interests.

To take the analogy further, the developers are no longer contractors possibly trying to stretch out the process. They are members of Joe?s accounting company, and they are just as keen to get to market fast as Joe is to start earning income. DevOps uses this synergy to achieve the overarching business goal.

A Brief Introduction to OpsDev

You can skip this section if you already read this article. If not then you need to know that DevOps is a culture, not a working method. The three ?members? are the software developers, the beneficiaries, and a quality control mechanism. The developers break their task into smaller chunks instead of releasing the code to quality control as a single batch. As a result, the review process happens contiguously along these simplified lines.

Code	QC	Test	?	?	?
?	Code	QC	Test	?	?
?	?	Code	QC	Test	?
?	?	?	Code	QC	Test

Colour Key

Developers

Quality Control

Beneficiary

This is a marked improvement over the previously cumbersome method below.

Write the Code	?	Test the Code	?	Use the Code
?	Evaluate, Schedule for Next Review			?

Working quickly and releasing smaller amounts of code means the OpsDev team learns quickly from mistakes, and should come to product release ahead of any competitor using the older, more linear method. The shared method of working releases huge resources in terms of user experience and in-line QC practices. Instead of being in a silo working on its own, development finds it has a richer brief and more support from being ?on the same side of the organisation?.

The Key Role that Application Program Interfaces Play

Application Program Interfaces, or API?s for short, are building blocks for software applications. Using proprietary software-bridges speeds this process up. A good example would be the PayPal applications that we find on so many websites today. API?s are not just for commercial sites, and they can reduce costs and improve efficiency considerably.

The following diagram courtesy of TIBCO illustrates how second-party applications integrate with PayPal architecture via an API fa?ade.

The DevOps Revolution Continues ?

We close with some important insights from an interview with Jim Stoneham. He was general manager of the Yahoo Communities business unit, at the time Flickr became a part. ?Flickr was a codebase,? Jim recalls, ?that evolved to operate at high scale over 7 years – and continuing to scale while adding and refining features was no small challenge. During this transition, it was a huge advantage that there was such an integrated dev and ops team?

The ?maturity model? as engineers refer to DevOps status currently, enables developers to learn faster, and deploy upgrades ahead of their competitors. This means the client reaches and exceeds break-even sooner. DevOps lubricates the value chain so companies add value to a product faster. One reason it worked so well with Flickr, was the immense trust between Dev and Ops, and that is a lesson we should learn.

?We transformed from a team of employees to a team of owners. When you move at that speed, and are looking at the numbers and the results daily, your investment level radically changes. This just can’t happen in teams that release quarterly, and it’s difficult even with monthly cycles.? (Jim Stoneham)

Contact Us

(+353)(0)1-443-3807 – IRL
(+44)(0)20-7193-9751 – UK

Check our similar posts

Can you do away with the Project Initiation Meeting?

Project initiation meetings are often skipped to fast-track projects. Once a sponsor is found, organisations go straight to project planning and execution. But based on our own experience, holding a project initiation meeting can actually eliminate many issues that may crop up in the future and hence may speed things up instead in the long run.

It is in the project initiation meeting where your project objectives and scope are clarified and all stakeholders are brought to the same page. Project sponsors and stakeholders will have to know in a nutshell what is needed from them, what the possible risks are, what different resources are required, and so on. So that, when it’s time to proceed to the next phase, everyone is already in-sync.

So what are taken up in such a meeting? Perhaps an actual example can help. Sometime in the past, we set out to work on an eCommerce website project. After conducting the project initiation meeting, these were some of the things we were able to accomplish:

Identified deliverables e.g. site design, interface to payment system, etc.
Come up with the project phases
Agreed what should be in and out of scope
Defined the acceptance test criteria
Identified possible risks
Identified the possible training and documentation work needed
Established whether any analysis was required, e.g. as with regards to payment interfaces
Formulated disaster recovery plans
Defined roles and responsibilities
Drafted timelines and due dates

Aren’t these covered in project planning? If the project is a big one, the answer is no. In a large project, project planning is a much more exhaustive activity. In a project initiation meeting, only the basic framework is defined.

Some questions may still remain unanswered after a project initiation meeting, but at least you already know what answers you need to look for. In the example we gave earlier, we left the meeting knowing that we needed:

a list of all necessary hardware to estimate the costs
to identify possible dependencies we might have with third parties
to identify what software had to be bought and what skills we needed to hire

When it was time to proceed to project planning, everyone involved already knew what direction we were taking. In effect, by not skipping the project initiation meeting, we were able to avoid many potential obstacles.

A Small External Enterprise Development Team is Cheaper than Your Own

Time is money in the application development business. We have to get to market sooner so someone else does not gazump us, and pip us at the post. We increase the likelihood of this with every delay. Moreover, the longer your in-house team takes to get you through the swamp, the higher the project cost to you.

Of course, in theory this should not be the case. Why bring in a team from outside, and pay more to support their corporate structure? Even going for a contract micro team ought not to make financial sense, because we have to fund their mark-up and their profit taking. Our common sense tells us that this is crazy. But, hold that thought for a minute. What would you say if a small external enterprise development team was actually cheaper? To achieve that, they would have to work faster too.

The costs of an Enterprise Internal Development Team

Even if you were able to keep your own team fully occupied ? which is unlikely in the long term ? having your own digital talent pool works out expensive when you factor in the total cost. Your difficulties begin with the hiring process, especially if you do not fully understand the project topic, and have to subcontract the hiring task.

If you decide to attempt this yourself, your learning curve could push out the project completion date. Whichever way you decide to go, you are up for paying advertising, orientation training, technical upskilling, travel expenses, and salaries all of which are going to rob your time. Moreover, a wrong recruitment decision would cost three times the new employee?s annual salary, and there is no sign of that changing.

But that is not all, not all by far. If want your in-house team to keep their work files in the office, then you are going to have to buy them laptops, plus extra screens so they can keep track of what they are doing. Those laptops are going to need desks, and those employees, chairs to sit in. Plus, you are going to need expensive workspace with good security for your team?s base.

If we really wanted to lay it on, we would add software / cloud costs, telephony, internet access, and ongoing technical training to the growing pile. We did a quick scan on PayScale. The median salary of a computer programmer in Ireland is ?38,000 per year and that is just the beginning. If you need a program manager for your computer software, their salary will be almost double that at ?65,000 annually.

Advantages of R&D outsourcing

The case for a small externally sourced enterprise development team revolves around the opportunity cost ? or loss to put in bluntly ? of hiring your own specialist staff for projects. If you own a smaller business with up to 100 people, you are going to have to find work for idle digital fingers, after you roll out your in-house enterprise project. If you do not, you head down the road towards owning a dysfunctional team lacking a core, shared objective to drive them forward.

Compared to this potential extravagance, hiring a small external enterprise development team on an as-needed basis makes far more sense. Using a good service provider as a ?convenience store? drives enterprise development costs down through the floor, relative to having your own permanent team. Moreover, the major savings that arise are in your hands and free to deploy as opportunities arise. A successful business is quick and nimble, with cash flow on tap for R & D.

Mobile Security

Today’s advanced enterprises make extensive use of mobile devices in order for team members to exchange information, collaborate, and carry out business whenever and wherever they need to. BlackBerries, iPhones, Google Phones, and other smartphones as well as PocketPCs and PDAs are now allowed wireless remote access to the enterprise network.

As a result, they introduce additional vulnerabilities into the system.

Bluetooth exploits and unencrypted passwords can allow malicious individuals to gain access to private information.
Various wireless technologies that have substantially simplified the task of transferring data have provided openings for malicious code. In addition, the diversity of these wireless technologies combined with the constrained environments of these devices have made it difficult to come up with an all-in-one solution.
All PocketPCs, PDAs and smartphones can be synchronised with PCs and laptops, giving malware an entry point into computers and networks. Memory cards are guilty of this too.
VoIP, which are usually unencrypted, allow other people to perform unauthorised capture and recording of private conversations.

Mobile security is still an emerging discipline. Because of this, many organisations that allow members’ mobile phone access into the network don’t actually have a specific security policy for such devices.

That’s why we’re here to help. We’ll conduct a thorough evaluation of your security policies and systems in relation to mobile devices and seal gaps we spot along the way. If you don’t have the needed policies or if what you have needs an overhaul, we’ll set everything up (including the needed applications and infrastructure) for you.

Once we’ve got everything in place, you won’t have to worry about the vulnerabilities mentioned earlier. In addition to that, your organisation will already be capable of preventing the following:

Access to company information when the phone ends up in the hands of anyone other than the authorised user.
Being billed for phone usage due to virus activity
Unauthorised phone activity monitoring through spyware
Other disruptions caused by mobile-based malware

Other defences we’re capable of putting up include: