devopsy.kinsta.cloud

Tag: it

Top 5 Traits of High-Performing Teams
DevOps is here and it seems to be what everyone in IT service management (ITSM) is buzzing about. So what are the goals and how do we know it’s not just the next hot kitchen color for this year? DevOps is a cultural and professional movement that stresses communication, collaboration and integration between software developers and IT operations professionals while leveraging agile, lean and traditional ITSM practices.

Stakeholders on the development side will include, but not be limited to, all of the people involved in developing software products and services. On the operations side it will include, but not be limited to, all of the people involved in delivering and managing those software products and services and the underlying IT infrastructure on which it is being delivered.

The goals are to better align IT responsiveness to business needs, smaller more frequent releases, reduce risk, increase flow, improve quality and reduce time to market. These can only be accomplished by understanding the entire value stream, including the lead times and cycle times of the different areas that make up your value stream.

Let’s take a look at the top five predictors of IT performance and see how engaging DevOps practices enhances our ability to become high-performing teams.
1. The peer review change approval process provides enhanced and effective communication. When technical teams hold themselves accountable for the quality of their code through peer review their performance increases, resulting in 200 more times frequent code deployments, according to Puppet Labs’ “2016 State of DevOps Report.” Allows for an on demand deployment (multiple, daily releases) structure.
2. Version control for all production artifacts. This provides a single source of truth for all changes. An integrated and automated tool chain along with practices such as continuous integration result in a three times lower failure rate, according to the report.
3. Proactive monitoring enables teams to diagnose and solve problems faster and have a higher degree of accountability. Tie that in with a single source of truth and that results in 24 times faster mean time to recovery (MTTR), the report noted.
4. High-trust organizational cultures allow for experimentation and learning, allowing people to take intelligent risks. Having this culture promotes the idea that repetition and practice is the prerequisite to mastery. According to the Puppet Labs report, organizations with high NPS (Net Promoter Score) have shown much higher levels of employee retention and are 2.2 times more likely to recommend their company as a good place to work.
5. A win-win relationship between Dev and Ops. It’s not Dev versus Ops, it’s Dev and Ops. Shifting left is about building quality into the software development process. When you shift left, fewer things break in production because issues are detected and resolved earlier. By building quality into the software development cycle, high-performing teams spend less time on unplanned work. We also found they spend less time remediating issues and spend more time on new, value-add work.
— Drew Lapatin
September 28, 2016
What the Auto Industry Can Teach IT Development

The latest and greatest advances in technology often draw the spotlight, but the truly great changes in business aren’t driven by technology alone. They’re enabled by a change in culture that’s supported and accelerated by technology.

Consider the assembly line in the auto industry. Automation, specialized tooling and robotics have provided a boost to quality and efficiency, but these advances only mattered because of a change in U.S. culture that emphasized speed, acceleration and economies of scale. Henry Ford capitalized on these cultural constructs to implement an innovative set of tools that revolutionized auto production. Toyota led the next evolution in auto manufacturing with its implementation of the Andon cord and Kaizen continuous improvement (CI) but similarly, these tools depend on a culture of trust and respect for the workers to be useful.

In the field of software development, a similar shift is taking place through the DevOps movement that’s leading to faster, more efficient and higher quality application development. Technology has made DevOps easier to implement, but these new tools only add value when they are accompanied or even implemented via a change in culture across the entire organization and all technology areas. This includes items such as visualizing the delivery value stream to identify areas for improvement, increased trust and collaboration across silos and a CI mindset.

A key aspect of DevOps is automation, and automation is only possible when patterns can be created, which requires eliminating any variances in practices and capabilities in all aspects of the organizations that don’t add value. For example, if every application is a snowflake in terms of its architecture and configuration, infrastructure automation won’t be possible. If release planning, management and deployment don’t have standard work associated with them, then again, an integrated delivery pipeline capability cannot be implemented.

Nationwide’s Journey to DevOps

At Nationwide, we began a change in how we developed applications almost a decade ago. At the time, the term was “agile.” We shifted application development to focus on smaller iterations of work with automated build and testing practices. While this proved valuable, we realized this was only part of the journey of accelerating our lead time from customer concept through delivery of business value.

We started the journey to implement a Lean-based DevOps model that encompasses the entire development value stream, from the incoming business request to application deployment and monitoring. Our goal was to work more closely with the business units to continuously plan, design, develop, test and deploy incremental improvements in our application-based products.

Nationwide has seen demonstrable benefits on this journey. Critical defects have declined by 80 percent, system availability is up 70 percent and on-time delivery of applications has risen to 90 percent from 60 percent. More importantly, we’re starting to see results in our business as we refine our ability to test business hypotheses and measure the results in terms of increased revenues.

Infrastructure to Support the Cultural Shift

Just as Ford’s auto assembly line utilized advanced technology to be successful (e.g. electricity enabled optimal placement of machines versus steam power), accelerated delivery is utilizing the development of new technologies. To advance DevOps, we use IBM Rational and UrbanCode software to manage and deploy applications. The new technology, though, has only worked because we have committed to both a technology and cultural change across our entire organization. We have more than 5,000 IT professionals on 200 different teams. Every team—whether it’s responsible for the mainframe, distributed, web or mobile— needs to utilize the same standard work approach to application development.

Let me give you one example of how that works: Biweekly show-and-tells are a core part of our approach. For new mobile applications, the changes after two weeks might be dramatic, but even for the larger applications running on our IBM z Systems mainframes, the teams have something to share. They break the mainframe application work into smaller units and demonstrate updates they’ve made that fit into more long-term initiatives.

The Autobahn for Application Development

While applications and products are not all developed at the same speed (e.g. a change to a mobile app versus a regulated change to back-end banking system), there is a need for these systems to utilize similar approaches and a common delivery pipeline with visibility of dependent changes, to be implemented as quickly as possible.

An example of this is a highway like the Autobahn accommodating different types of drivers and vehicles, such as a Porsche built for speed and a semi-truck built to carry cargo. The rules of the highway allow vehicles to drive at different speeds safely without having stoplights by providing exit and entrance ramps, speed limit minimums and visibility of other vehicles along with “standard rules of the road.”

Likewise, we want our IT delivery capability to accommodate variable speeds of IT based on the business needs and the development teams’ abilities to go faster by implementing practices such as smaller batch sizes, APIs and microservices, feature flags and performing automated testing and readiness validation. While distributed and mobile applications might be the Porsches on the road, they can only go as fast as the mainframe and legacy applications, or semi-trucks and other traffic will allow.

Consequences of Resisting Change

No company will get through the next decade without being disrupted, either externally or internally via a continuous improvement and innovation mindset. Those that embrace Lean and DevOps practices across the entire IT organization will have a steady stream of new services and improvements that outpaces the competition and transforms their business. Those who don’t will join former Fortune 500 companies that waited too long to realize that their competitor’s Porsches and semi-trucks were too far along to catch up with.

About the Authors / Carmen DeArdo and Jason Patterson

Carmen DeArdo is the director of Build Technologies at Nationwide Insurance. He is responsible for helping drive accelerated delivery utilizing Lean and DevOps techniques across the end-to-end delivery value stream. One current focus area is the creation of an integrated delivery pipeline capability.

Jason Patterson is a Lean and Agile coach at Nationwide Insurance. He works with development and support teams across the company to help recognize process gaps and opportunities in their delivery stream. His background in development fuels that energy, while he resists the urge to automate every broken or unnecessary process. After nearly a decade at Nationwide and seven years experimenting with extreme programming, scrum and agile methods in a software development department at Indiana University, Jason is still learning.

August 17, 2016
REP SPOTLIGHT: Soft2Solve

DevOps Institute: Tell us a little about your organization,

Soft2Solve: We work with our customers in order to help them to enhance IT performance, saving cost, and training on best methods, process and practices, selecting at the same time the best solutions for Spanish Speaker Customers.

DevOps Institute: What other topics do you teach or consult on?

Soft2Solve: Cost savings in some specific areas as printing, energy.

DevOps Institute: What type of interest in DevOps are you seeing in your region?

Soft2Solve: The interest is initial. Most of customer are aware of DevOps initiatives, but they are still learning and looking how movement evolves and how they can set up the practices on their companies. Some of them already started with agile methodologies in development.

In the other side, most of them already have ITSM practices implemented, based mainly in ITIL.

DevOps Institute: How do you think that DevOps contributes to the business’ value stream?

Soft2Solve: First, aligning IT with the business requirements in terms of speed, flexibility and agility. Then it contributes to analyze the bad processes in place and getting high cost savings when implementing DevOps practices. It also enhances the internal relationships between IT departments, as usually there is a big fight between them. Also, that impact on quality and speed to answer the business.

DevOps Institute: What topic area in DevOps excites you the most?

Soft2Solve: It is an IT answer to the business requirements to follow the business needs; meanwhile, being more productive and less expensive. In other areas, the automatization is a base for DevOps.

DevOps Institute: Why should enterprises and individuals consider formal DevOps Training?

Soft2Solve: Although sometimes the organizations do not know, any new change—especially culture changes—need internal sponsors as much as possible in the organizations. These people have to be trained by third-party independent people outside their organizations that are aseptic and not influenced from the internal existing culture and way of doing. These people will be the people that will support the change and the IT alignment with the business organization and will answer quickly to business requirements.

July 12, 2016
REP SPOTLIGHT: Omnikron

DevOps Institute: Tell us a little about your organization.

Omnikron: With over 30 years of industry experience, we have honed IT and project management training techniques to ensure that course material caters to our clients’ needs. Our training is not just lectures from a book. We offer world-class courses, assessments and simulations in a variety of formats and at various paces. As the workplace has changed in the 21st century, so has the training approach here at Omnikron.

DevOps Institute: What other topics do you teach or consult on?

Omnikron: Omnikron’s most popular training includes ITIL, PMP, TOGAF9, Change Management, DevOps, Security & Security Awareness and Cloud.

DevOps Institute: What type of interest in DevOps are you seeing in your region?

Omnikron: There is a lot of talk about DevOps and our classes are slowly but surely increasing in size. Hopefully by the end of the year, we will have a packed house for our classes.

DevOps Institute: How do you think that DevOps contributes to the business’ value stream?

Omnikron: We have honed in on ITIL for years and DevOps is such an easy transition for most of our students. Not only are the students enjoying the class, but they are able to use their past experience to share stories in class as well as apply what they have learned outside the class.

DevOps Institute: What topic area in DevOps excites you the most?

Omnikron: Organization consideration and practices seems to be the favorite among our students. Plenty of dialogue has been given around this particular topic.

DevOps Institute: Why should enterprises and individuals consider formal DevOps training?

Omnikron: Because DevOps is designed to help our student continually improve their services to their internal and external customers. Can’t get any better than that!

July 5, 2016
Rep Spotlight: Global Lynx

DevOps Institute: Tell us a little about your organization:

Global Lynx: Global Lynx is a leading and fast-growing IT consulting and training company that assists companies and government agencies improve the competence and skills of their IT organization, enhance the maturity of their IT governance and improve the quality and effectiveness of their IT operations, services and processes.

Since 1996, Global Lynx experts have helped organizations in five different countries, improving—and often transforming—their IT operations through the implementation of effective frameworks for IT governance, ITSM (IT services management), PMO (project management office) and information security.

As an Accredited Training Organization (ATO), Global Lynx also offers a wide variety of IT courseware covering different areas, standards, frameworks and methodologies, and at various levels of expertise.

Global Lynx trainers are experienced consultants, certified in multiple IT disciplines. They have actual firsthand experience in their areas of IT expertise, as well as experience in delivering training programs.

DOI: What other topics do you teach or consult on?

Global Lynx: IT service management, IT corporate governance, IT audit, information security, cyber resilience, IT risk management, cloud computing, project management, SCRUM, business continuity, process design and implementation, and enterprise value creation.

DOI: What type of interest in DevOps are you seeing in your region?

Global Lynx: Companies are interested in obtaining a common understanding of DevOps concepts and best practices, and they are focusing on deploying these practices organization-wide.

DOI: How do you think that DevOps contributes to the business’s value stream?

Global Lynx: The digital disruption all industries are experiencing, has created the need for IT to be embedded in every single business unit. Solid DevOps practices will help IT organizations deliver higher value to their customers, as value is delivered through operations, but it is defined and enabled in the development stages. Value should be managed not only in operations, but rather from the early stages of the service life cycle. A mature IT organization cannot have a poor collaboration and communication culture; without this, value creation will be limited to technical value instead of real business value.

DOI: What topic area in DevOps excites you the most?

Global Lynx: How DevOps interfaces other frameworks and how all of them can work together toward creating value to the customer.

DOI: Why should enterprises and individuals consider formal DevOps training?

Global Lynx: DevOps is all about people, and it is enabled by people. If a person is not committed, that person will do little to support the DevOps initiative. People need to go through formal DevOps training to learn what DevOps is, and how their role impacts the initiative and how they contribute to value creation. Certification is a plus, as it gives people a personal benefit. People will naturally react positively to something they own, because they will believe in it.

June 3, 2016
What is a DevOps ‘Best Practice’?
In IT, we love our frameworks. Whether agile, ITIL, lean, cobit, six sigma or others, our thirst for “best practice” guidance seems to be unquenchable.

The concept of a “best practice” is an enigma. Who decides if a practice is actually the best? And best for whom? While an “adopt and adapt” mentality is advocated in most frameworks, there is still a tendency to benchmark efforts against and conform to published best practices. Whether promoting “best in breed,” “world-class,” or “best practices,” many organizations swing these terms around as some form of competitive advantage.

Is it really? Shouldn’t business outcomes be the real competitive advantage and measure whether IT’s practices are really the “best” to meet customer requirements?

The DevOps Institute was founded in 2015 as a global learning community for emerging DevOps practices. Since our launch, we have intentionally avoided any reference to DevOps “best practices.”

We believe that DevOps practices are constantly emerging and, in many cases, being proven in the wild.

Through research, interviews, conferences and the experience of our Regents and partners, DOI’s goal is to identify, capture and share emerging DevOps practices through knowledge, education and certification models that best serve the learning community and enterprise IT. We feel it is premature to certify an individual as an “Expert” or “Master” when the expertise and mastery needed for successful DevOps is not clear and may not be appropriate in a single person.

DevOps is fairly young. It does not have a single body of knowledge. There is disagreement on whether it is a philosophy, movement or framework. Despite that, DevOps is crossing the chasm from innovators to the early majority faster than any other IT framework. Why? Perhaps it is because DevOps speaks to many of the cultural and technical challenges that IT has been amassing for years.

So instead of focusing on best practices, let’s agree on DevOps’ core principles:
- Go faster
- Shorten feedback loops
- Experiment and learn
- Cultural transformation
- Deliver business and customer value constantly and consistently
No doubt, some practices have clearly risen as being critical to the realization of DevOps’ core principles:
- Agile software development
- Continuous integration
- Continuous delivery pipelines
- Automated and continuous testing
- Proactive monitoring
- Improved communication and collaboration
Still, over the past year, DOI has seen additional practices gain interest
- DevSecOps/rugged DevOps
- ChatOps
- Agile service management
- Lean
- Immersion practices (Garage, Lofts, Dojos)
- DevOps teams
What will emerge next year? Who knows—but that’s the exciting part of DevOps. As time passes, there is less contradiction and more supplementation. Each emerging practice seems to complement and fine tune what came before.

Even without a standard definition, DevOps is already encouraging organizations to examine their proprietary practices, identify gaps, assess their automation and, most importantly, engage in collaborative discussions. Transformations have taken seed without defined best practices. That’s awesome! Let’s not quell the momentum by attaching a static set of best practices.

Will DevOps’ best practices eventually be agreed? Maybe. DevOps touches almost every aspect of IT management—people, practices and automation. That’s a tall order for a set best practices. Certainly some will try to publish their version of a “definitive” DevOps body of knowledge. Even “The DevOps Handbook,” an important book publishing later this year, was built as a collaborative effort between many of the early founders of the DevOps movement. Their perspective and insight will be awesome but not finite.

I understand the frustration by the lack of a single body of knowledge and prescribed best practices. In past frameworks, the body of knowledge was both a enabling tool and constraining limitation. Bodies of knowledge are difficult to keep current. For DevOps, let’s embrace the concepts of spirit of sharing, collaboration and continuous innovation by promoting an inclusive and collective body of knowledge of emerging practices.

If we settle on a set of DevOps best practices, are we actually inhibiting the very values that we are trying to instill? I hope not.
May 27, 2016
What to Expect: DevOps Enterprise Summit London
After the success of the first two years of the U.S. DevOps Enterprise Summit, people have been asking us to host a similar conference in other locations, specifically in Europe. This summer, we’re hosting our first DevOps Enterprise Summit in London!

This conference is for technology leaders who are driving transformations in large, complex organizations. These are successful enterprises that have been around for decades (and, in some cases, for centuries!), with thousands (or tens of thousands) of employees, and billions of dollars in annual revenue. These are organizations with massive and complex daily operations, and all the resulting processes and bureaucracies that come with it. In many ways, these complex operations and bureaucracies are the very things that create the worst-case conditions for DevOps transformations!

We’ve heard amazing case studies from Barclays Capital, GE Capital, Disney, Marks & Spencer, Bank of America, Capital One, Telstra and many more, where leaders have created amazing DevOps outcomes that are more typically associated with organizations such as Google, Amazon, Facebook and so forth.

For this inaugural year of DevOps Enterprise Summit London, we’ll be bringing some of our “greatest hits” from the United States, but the rest of the programming will feature DevOps transformations in organizations residing in the U.K. and continental Europe. (And we’re still holding the DevOps Enterprise Summit in San Francisco, so feel free to join us there as well!)

New World and Old World DevOps

The speakers at DevOps Enterprise are pioneering the practices of how large, complex organizations transform and deliver software. It’s my belief that these principles are universal, regardless of what continent or country the organization resides in.

One of the biggest surprises from co-authoring “The Phoenix Project” has been how many people have told me that the book describes their organization, seemingly independent of company size, industry vertical, for-profit or nonprofit or the continent they’re writing from. This validates that the problems that result when Dev and Ops can’t get along are universal.

The good news is that the DevOps solutions we deploy to fix the problems also have lots of commonalities!

It’s always inspiring to hear how these leaders have overcome the challenges they faced. I see our speakers as genuine heroes who have put themselves in personal jeopardy, often risking their careers and livelihoods, to achieve something they believe is genuinely important. They possessed the clarity and conviction that the capabilities they were creating for their organizations were needed to win in the marketplace—or maybe even just to survive.

I think one of the interesting statistics is that more than 25 percent of DevOps Enterprise speakers have been promoted in the last two years—some more than once! It’s a fantastic testament that the organization values the contributions they have made, and their risk-taking and heroism paid off.

The DevOps Movement Matures

Every year at the DevOps Enterprise Summit, I have asked all speakers to share what problems they didn’t know how to fix or the problems that they were looking for help on. What I’ve found is that the answers have evolved. From year to year, we are seeing trends on the obstacles facing the DevOps Enterprise community.

In 2014, attendees’ stated problems were about needing better strategies and tactics for creating automated tests for legacy applications, as well as the culture and leadership aspects during transformation, information security and compliance practices and identifying metrics to best improve performance with DevOps initiatives.

In 2015, the problems were focused on people and organizational design. Examples included the need for effective strategies and methods for leading change in large organizations. Speakers and attendees also wanted to know what the organization charts looked like for organizations successfully adopting DevOps. What were the respective roles and responsibilities, and how had they changed from more traditional IT organizations?

Now, as we approach DevOps Enterprise Summit 2016, we are seeking to address the next phase of challenges facing the community: What are the modern architectural and technical practices that every technology leader needs to know about? What are the technology practices for managing infrastructure, environments and automated testing? And what are the transition patterns to get there?

From the HR perspective, how do you go about reskilling the workforce and employing these new design patterns? Lastly, we are seeing compliance and security discussed more often, including: What are concrete ways for DevOps to bridge the information security and compliance gap to show auditors and regulators that effective controls exist to prevent, detect and correct problems?

The programming committee always invites a handful of speakers to return from year to year. While to some this might appear redundant, it’s actually quite fascinating to witness their journeys unfold. It’s like an episode of, “Where Are They Now,” and the speakers never cease to amaze!

Solving Problems Together

As a vendor-neutral conference, DevOps Enterprise Summit curates stories that are from the enterprise point-of-view. Most of the presentations follow a very specific “experience report” structure—speakers describe their organization and their industry, the business problem they faced, where they started their transformation, what they did and the business outcomes. It’s a simple format but very powerful because it helps other people facing the same problems learn how other people solved the problem, and it often reveals practices that can be used in other contexts.

I’m so excited to share some of the initial speakers we have slated for DOES London:
- Chris Jackson, Director of Cloud Product Engineering at Pearson
- Robin Hughes, Head of Development Services at LV=
- Justin Dean, SVP, Platform and Technical Operations at Ticketmaster
- Jeremy Waite, Chief Digital Strategist at Salesforce
- Gareth Rushgrove, Senior Software Engineer at Puppet Labs, Inc; ex-UK GDS
- Antony Collard, Deputy Director at HMRC
- Finbarr Joy, Group CTO at Lebara
- Amy Philipps, Head of Test at Songkick
- Jason Cox, Director, Systems Engineering at The Walt Disney Company
- Rosalind Radcliffe, Distinguished Engineer, Chief Architect for DevOps for Enterprise System at IBM
What also amazes me about DevOps Enterprise is the concentration of talent in the technology leaders who attend—they’re all people who are passionate about technology and helping teams win, and willing to do disruptive things to get there.

Ross Clanton from Target (a large U.S. retailer) told me he valued being surrounded by people who were not only trying to solve the same problems that he was facing, but were the best in the game—and there’s a huge intrinsic value of being surrounded by those kind of people. I can definitely relate; I learn something in every one of my interactions at the conference, and I have no doubt that the practices this group is pioneering will be commonplace within a generation.

Like in any aspect of life, peers are important. As Buzz Aldrin said, “Show me your friends, and I will show you your future.”

DOES is a unique opportunity to meet some very talented and inspirational new friends who can help shape your career path. We hope you’ll join us in London.

DevOps Enterprise Summit London

June 30 & July 1, 2016

Hilton London Metropole

225 Edgware Road, London, UK

@DOESsummitEU

Early Bird £600 +VAT (ends May 2)

DevOps Enterprise Summit San Francisco

November 7–9, 2016

Hilton San Francisco Union Square

333 O’Farrell Street, San Francisco, CA

@DOESsummit

Early Bird $1,450 (ends May 16)
Check out videos from previous DevOps Enterprise Summits on YouTube.
April 21, 2016
Submit your proposal for DevOps Enterprise Summit San Francisco!

The theme for this year’s #DOES16 San Francisco conference is Leading Change.

We want to hear stories from the leaders of large, complex organizations implementing DevOps principles and practices.

The submission deadline is midnight PDT, May 2, 2016.

All submissions will be notified by June 17, 2016.

Get details >>>

This year’s programming will be based on a series of survey questions about the biggest issues IT professionals continue to work with. Several universal topics emerged, and we will be selecting talks that address them:

People and Culture: We’re interested in the strategies and methods you employed to successfully lead change and to enable DevOps outcomes in large organizations. How did your approach to leadership and organizational design differ from those used in more traditional IT organizations? How is the workforce different, both for employees as well as contractors and outsourcers? And what have been your results?

Process and Technology: We are interested in the practices you have adopted to integrate change into your workforce and build on changing relationships with your vendors. What are modern architectural and technical practices that every technology leader needs to know about?

Compliance and Security: We’re interested in concrete ways you have helped DevOps bridge the information security and compliance gap, showing auditors and regulators that effective controls exist to prevent, detect, and correct problems.
Submit your proposal >>>

For the full news release, click here.

EARLY BIRD TICKETS ON SALE NOW!

If you missed the Blind Bird tickets, don’t fret.

We are offering a discounted Early Bird rate for $1,450 (ends May 16). That’s a savings of more than 25% off the full-price ticket.

We encourage you to act quickly as the past two years have sold out.

Get tickets >>>

April 11, 2016
IT Organization: Blend, Don’t Divide
Bi-modal is the new normal, but the best way to approach this is to blend operations, not create separate groups.

There’s been much ado lately about the transition of enterprise IT from traditional, steady operations to a highly agile and services-based operation. Companies of all sizes are moving to the cloud and adopting DevOps, yet many must maintain legacy systems for years to come. Pundits and analysts such as Gartner suggest that CIOs need to split their organizations into two: the Mode 1 group (traditional, “lights on” operations) and Mode 2 (the business-innovating group). In fact, Gartner is so bullish on this idea that the research firm is predicting that 72 percent of enterprises will be operating in a bimodal structure by 2017.

Yet dividing and conquering won’t work. By creating two separate groups, with likely two different leaders, there’s bound to be tension and turf wars. Overlap of duties will happen, and higher costs may result. Regardless, the two groups will still need to work together—but may have little incentive to do so.

Let’s take a step back. Bimodal is just another name for transitions that IT organizations have been through many times in the past: analog vs. digital, mainframe vs. client/server, batch vs. interactive, native vs. web-based, on-premises vs. cloud and so on. Creating walls between existing and emerging processes and technologies doesn’t make much sense. It’s possible to manage “old” and the “new” requirements and projects in tangent.

Instead of creating walls, Mode 1 and Mode 2 processes can coexist and employees with different perspectives can help each other as the company transitions to its next phase of innovation. Over time, the entire organization will shift to the most progressive, efficient and business-aligned way of delivering IT.

IT organizations should think more holistically about building cross-functional teams made up of the best members to serve that team’s particular purpose. Those teams may have mobile app developers and DevOps managers sitting side by side with network engineers and system architects who have developed deep specialties in enterprise databases and data center infrastructure over many years. There may be Waterfall teams and DevOps teams, and individuals managing cloud providers working closely with data center managers implementing converged infrastructure. It all begins with the business requirements and designing a strategy that is inclusive of both required legacy systems and future, cloud-based initiatives.

But wait, aren’t the most progressive companies Mode 2 from top to bottom? The answer is no. Companies such as Amazon, Google, Netflix, Facebook, Apple and LinkedIn are IT innovators that also manage solid and stable internal environments.

It was only in mid-2015 that Apple announced its migration of the Siri application platform to the Apache Mesos platform. This didn’t happen overnight. The team responsible for Siri realized that it could cut costs and increase flexibility for ongoing support and development. It was an evolutionary move focused on front-end scalability and allowing a clustered approach for scale and management—arguably a very Mode 2 approach. That said, it’s also widely known that the data sources for Siri are a mix of traditional RDBMS and No-SQL—massive data repositories handling millions of transactions 24/7. These platforms require Mode 1, utility-grade availability constructs.

LinkedIn is another innovator running a distributed architecture that blends Mode 1 technologies (data layer and business engines) with Mode 2 clusters focused on presentation of new and existing initiatives.

Ways to Blend Effectively

Here are some ways to approach a blended IT organization that incorporate both Mode 1 and 2 technologies and processes without building walls:
1. Create a best-of-breed environment. Evaluate your applications and create an architecture plan. Identify existing applications that require modernization. Create a clear picture of the gap between current and desired state. Build an architecture for your applications that leverages one or more platforms that can adapt to your application architecture goals, both present and future.
2. Balance out your weakness. Most large companies in traditional industries will be heavier on the Mode 1 orientation regarding skill sets, tools and processes. To jump-start a transition toward Mode 2 operations, consider hiring people from software startups with ample experience developing, scaling and maintaining cloud-based systems under rapid time frames. These are the people whose failures bring the perspective necessary to empathize with your Mode 1 teams. They might even appreciate the Mode 1 team’s experience.
  Conversely, if your organization is already a strong Mode 2 operation, know that scaling your business will require you to embrace Mode 1 skills to maintain reliability and consistent user experience as demand grows unpredictably. Ideally, find someone with a large enterprise background that has experience delivering reliability for new, web-scale applications.
1. Don’t force new methods. DevOps, a technique for infrastructure management in support of rapid delivery of applications services that is generally considered to be well-suited for Mode 2 applications, may not retrofit to every situation. For example, one can write code to manage infrastructure systems that expand and contract with the proliferation of application containers. While well-suited for the container-based application model, many of the coding concepts associated can be too complex for scripting the deployment of a multi-tier Mode 1 application. The layers and complexities of the scripting don’t provide enough return on the time invested to justify the upfront efforts. Leveraging a purpose-built automation engine or simply deploying manually likely makes more sense today. Choose the technique that best serves the initiative, not the one that seems the newest and coolest.
Rather than getting hung up on how to reorganize IT departments, a better use of time is to determine how to blend the best of the old and the new. IT organizations today are frequently in a state of transition, given the pace of new technological developments. By merging tried-and-true tools and practices that deliver stability with the latest innovations for web-scale business models, companies can move quickly in their respective markets without sacrificing business longevity.

About the Author/Steve McDonald

Steve McDonald is Vice President of Product at StrataCloud, developer of a platform for software-defining enterprise data centers. Over the past 15-plus years, McDonald has led cross-functional teams in the delivery of innovative business initiatives, most recently at Softchoice, where he a managed a team of business development and pre-sales professionals in the United States and Canada focused on the profitable growth of the entire Cisco portfolio as well the networking category overall.
March 31, 2016
Security at the Speed of Innovation
With the advent of the cloud and platform as a service (PaaS) offerings, developers are innovating faster than ever. But with this rapid pace comes risk. Companies quickly implement new apps to meet their business demands, but the increasing complexity of the infrastructure being used – both in the cloud, on premise, or a hybrid combination – makes it difficult to ensure vulnerabilities are not introduced or vital corporate information is not exposed. In the quest to ensure that policy and governance are in place and security risks are negated, IT often brings innovation to a screeching halt.

Is there a happy medium that enables developers to continue accelerating innovation, but makes IT confident there’s adequate security? In this article, we’ll look at the importance of governance and policy, and outline the five fundamental security requirements that will help enterprises bridge that chasm that currently separates development and IT.

Policy Debt – The Downside of Faster Innovation

Security flaws are not new. Enterprises have faced serious security problems for decades. As today’s computing landscape becomes increasingly diverse and complex with increasing use of the cloud, new vulnerabilities are introduced, which exacerbate problems with existing security methods, such as simple usernames and passwords and an over-reliance on network perimeter security models.

The rapid introduction of new developer technologies far outpaces an enterprise’s ability to vet them. As a result, enterprise IT faces a tradeoff: rapidly adopt new technologies to satiate business demands thereby accepting more risk, or slow down new technology adoption with the hope of mitigating risk. Tension between enterprise IT and the rest of the business is the inevitable outcome. More importantly, because new apps have so many dependencies, as soon as one is put into production, an enterprise almost immediately incurs policy debt.

Policy should enable enterprises to track these dependencies, but in today’s IT environments, each piece of infrastructure or cloud resource has its own unique policy model, operational mode and lifecycle. As a result, enterprises end up with a layered cake of dependencies, which is difficult to keep track of and ensure no security holes are left unpatched.

Most of today’s security technologies – like gateways and firewalls – are either point-based or palliative solutions. They treat symptoms rather than root causes. And, they only work for traffic that’s routed through them, which precludes most of the server-to-server interactions that happen within the datacenter. Reliance on gateways is akin to locking the deadbolt on the front door of your house but leaving the back door open.

These simply are not enough to address the proliferation of attacks that have paralyzed companies and exposed customer and consumer data. Consider the three major security Linux exploits – Ghost, Shellshock and Heartbleed – that came to light in the past year. To patch their systems against these problems, companies needed to find the vulnerabilities and reset servers to activate the fix, which resulted in a cascading failure of servers, downtime and a host of other performance-related issues – simply because there’s no centralized way to apply policy and determine whether a resource in use is vulnerable.

The Fundamental Five Security Requirements in the Brave New IT World

To fully protect their increasingly complex IT environments, there are five fundamental security requirements no enterprise should be without:
1. Resource Naming and Identity – To secure access of a workload or process, it needs to be named so that it can referenced as logic is applied. There is no notion of identity for the applications running today. They’re simply workloads running on a CPU. If enterprises want to apply policy, they will need an overlay operating system that gives identity to that workload, so it can be organized into a manageable, policy-driven hierarchy. This type of naming scheme is being done for Internet domains, but there is nothing comparable for the data center that enables IT to find, maintain and operate workloads residing there, regardless of where they are physically run.
2. Chain of Trust – In today’s data center topologies, no actual proof is needed to ensure that a holder of a token is exactly who it claims to be. To guarantee a high level of proof of identity and actual trust of components, enterprises require a central signing authority that issues tokens to all clients and internal components. This ensures that the management backplane is resilient to token and credential theft, and the system offers a high degree of trust.
3. Context Aware Policy – Most systems rely solely on role membership to make authorization decisions, such as “who” can do “what” to “what.” But enterprises need to go further than that, with the use of a dynamic scripting language for authorization decisions. Every authorization decision will require information over and above simple role membership (date and time, authentication strength, targeted resource and more). The result is a system that adapts more easily to enterprise authorization requirements.
4. Control of the Network – The network is a vital part of any enterprise system, and controlling access to network nodes is key for enterprise IT governance. Today, network access control is a hodge-podge combination of network perimeters, firewalls, VLANs, VXLans, proxies and security appliances. Workloads exist in network segments and workload connectivity is a function of network segment configuration. Over time, these configurations become rigid, brittle and difficult to maintain. To prevent this, enterprises need to control the network within the cluster so that any workload running must be given explicit access to the network and other workloads (via policy) in real time and regardless of physical properties of the infrastructure.
5. Ephemeral Service Credentials – Applications and services require connectivity and sometimes credentials to talk to one another. Once an application gets a credential for a service, the application becomes responsible for safeguarding that credential. However, credentials sometimes leak — they can appear in log files or configuration files, and can even be scraped from memory. What enterprises need is a new approach to service access that binds a credential to an individual network path. This ensures that even if a credential were to leak, it couldn’t be used from another location on the network. Moreover, with this method credentials live only as long as an individual workload in the system, rotating every time the application stops and starts again. By taking this approach, the burden on applications for handling credentials is reduced, strains of NetOps and network perimeter security models at scale decreases, and weak links in the trust chain are removed. The result is a more secure system that you can trust without changing your existing investments.
About the Author/Derek Collison

Derek Collison is founder and CEO of Apcera. An industry veteran and pioneer in large-scale distributed systems and enterprise computing, Derek has held executive positions at VMware, Google and TIBCO Software. As CTO and chief architect of cloud application platforms at VMware, he co-founded the cloud computing group and designed and architected Cloud Foundry,the industry’s first open PaaS. During his time at Google, he co-founded the AJAX APIs group.
July 9, 2015