devopsy.kinsta.cloud

Category: Enterprise DevOps

Change Management & Continuous Delivery: Clash or Harmony?
Introducing changes into running software systems is risky. There’s always a chance of failure, and that can have a negative impact on your business. It’s important to mitigate that risk, but there’s more than one way to do so.

Change Management is all about ensuring that changes to existing systems and software in production are done in a controlled way. Change managers review the changes that are to be implemented, assess their impact, and perform due diligence, before giving or withholding their approval.

Continuous Delivery (CD) is about improving the process of delivering software and increasing efficiency. It aims to cut down the time between ideation and realization. It’s about reducing the scope for error and increasing the speed to market to generate a competitive advantage.

Is there an inevitable clash between CM and CD? Are they really compatible? At heart, the CD pipeline is intended to achieve the same thing as CM by enabling the smooth, error-free roll-out of changes, but today they are usually coming from very different angles.

If CM is to have a future in the CD revolution, then it needs to change. Before we discuss how that might be achieved, let’s take a look at the current state of play

Is Change Management delivering?

Ask yourself what impact change management is having on your organization. If change management was working perfectly then there wouldn’t be any production problems, and yet issues still crop up. There are a few things to consider:
1. How many entries in the CM checklist could be automated? Is the change manager doing anything that really requires human input? Fact collection and verification could be a part of your CD pipeline.
2. How much value do check boxes deliver in the first place? What is change management really bringing to the table?
3. Is the process fit for purpose? Does it actually prevent problems, or is the change manager really just a fall guy, there to sign off on the release and take the blame if something goes wrong?
Clashing with Continuous Delivery

CM is intimately linked with the idea and practice of big complicated transformations, but with CD we’re not talking about enormous, disruptive changes. CD is about changing small parts of a system and doing it often. The risk to reward ratio is different when you think and work iteratively. Smaller change sets are less likely to cause problems and easier to rollback when they do.

Does the process really require human input? Heavyweight validation will slow it down and speed is one of the key benefits Continuous Delivery offers. Streamlining and automating the checklist process makes perfect sense in many business contexts. The aims of CM and CD are in sync, but CD is better placed to deliver.

A possible advantage of traditional CM is the presence of a human eye, offering intuition that a machine or a piece of software may not be capable of. By moving beyond the checklists and reimagining the CM role we can retain this advantage and push CD forward.

From Gatekeepers to Masters of Continuous Delivery

If the bulk of CM is really an administrative exercise in checking boxes then it could be an unnecessary overhead, but there is a way to retain that human oversight for organizations wary of full automation. Why not ask the former gatekeeper to own the CD process? For a CD pipeline to be truly effective someone has to guide the process, engage with all the teams involved and understand exactly why and how the process generates business value.

A change manager, paired with a build or release engineer to handle the automation, could work to help organizations move towards CD. They are uniquely well placed to identify dependencies, map processes, and help construct the CD pipeline with minimal disruption. They can help sketch out what the pipeline should verify, what data and dependencies need to be taken into account, what automated tests are required, and how it fits with other components to automate that release procedure. They also have experience mediating between business and IT.

The traditional CM approach of committee meetings and spreadsheet checklists is dated, and for many organizations it no longer makes sense. You can find much greater business value in focusing on an efficient rollback procedure that kicks in immediately and automatically when changes fail.

Take a look at your CM and ask yourself – is it really adding anything to the process, or is it just another bottleneck? It may be time for a change.

About the Author/Andrew Phillips

Andrew Phillips heads up product management at XebiaLabs. Andrew is an evangelist and thought leader in the DevOps, Cloud and Continuous Delivery space. He sits on the management team and drives product direction, positioning and planning.
January 21, 2015
Awkward questions for those getting started with automation
This blog asking awkward questions for folks jumping on the microservices bandwagon was enlightening from the perspective that many of the same questions are applicable to operations as they begin to tackle operationalizing all the things in an application lifecycle.

For example: “What is your deployable unit?”

Great question, isn’t it? What is your deployable unit of automation? Is it per service? Per device? Per cluster of devices? Per container?

Wait, but there’s more from this great list of awkward questions:

Is it acceptable for another team to take your code and spin up another instance of your microservice?

Can team A use team B’s microservice or are they only used within rather than between teams?

Do you have consumer contacts for your microservices or is it the consumer’s responsibility to keep up with the changes to your API?

Is each microservice a snowflake or are there common conventions?

How are these conventions enforced?

How are these conventions documented?

What’s involved in supporting these conventions?

Are there common libraries that help with supporting these conventions?

All these questions are applicable to devops, in particular, as you go about building out automated scripts, systems and orchestrating processes that operationalize the data center and make it a lean, green deployment machine.

You are going to have some kind of code, whether it’s a script or a recipe or a template of some kind, and questions regarding the usage of that code is important. Can others use it? Change it? Claim it as their own? Are they useful in a general, “here’s a basic load balancing provisioning and configuration script” or are they specific, as in “this is a piece of code that provisions and configures the networking required to ensure all 18 tiers of this very specific application can communicate”?

And as you’re developing those scripts (that code) are you documenting it? Are there <gasp> comments? Do you use a standard convention for code formatting (cause let me tell you, where you place your brackets is a matter of great technical religious significance)?

Most of those jumping into automation head first aren’t thinking of the long term ramifications of the choices they are making right now. Proof of concepts turn into pilots that turn into systems upon which all of IT relies. Rarely are you given the opportunity to go back and put any kind of standard conventions or practices into place. That’s what builds technical debt in software and, no matter what you think you’re building with those scripts, you’re building software.

Adopting the technical and methodological practices of agile development is a good thing, but let’s not ignore that along the way from waterfall to agile developers have learned a lot of lessons the hard way. That means we should, as practitioners of software-related activities within operations (and that means any one of the four operations groups in IT), pay attention to those lessons and try to avoid the pitfalls that developers have already encountered and, one hopes, overcome.

To do that, don’t just ask the awkward questions; answer them.
January 7, 2015
Commercial vendors gift to DevOps

Open source solutions are usually brought to life because of someone’s yearning to solve a problem and share the solution with the rest of the world. Or perhaps when inventors are merely trying to get more eyes on the code for help with hidden bugs and fixes.

(more…)

January 6, 2015
Top Skills for Enterprise DevOps
There is one question I hear almost every time I talk with my large enterprise customers about DevOps:
1. What skills do my people need to be successful with DevOps?
Talk of DevOps almost immediately focuses on culture – like having empathy for fellow workers, being flexible and adaptable, seeking continuous improvement, building relationships, etc. However, while critically important in DevOps, culture is an outcome, not an input; and such attributes are mostly either innate or acquired slowly. Culture cannot easily be taught.

At the other end of the spectrum, we often look at technologies – agile development, coding languages, virtualization/cloud platforms, management tools, etc. Again, these can be important, but while learning these skills might make you a better dev or op, they may not make you a DevOps practitioner.

Like most transformations, DevOps will need new people, process and technology skills, so in this post I take a look at a handful of the most important, pragmatic, and trainable skills in all three areas for practitioners looking to adopt DevOps, especially in large and more complex organizations.

People Skills
- Communication skills – while this may not come easily to typically introverted IT staff, both written and verbal communications, within and across the organization, and even with customers, are essential to a strong DevOps approach. This skill is learnable from formal courses, groups like Toastmasters, direct mentoring, social activities, or informal sessions like ‘lunch and learn.’ For extra credit, jump on stage for open mic night at a local comedy club!
- Business alignment – much of a dev or ops life is spent embedded in the technology of software delivery, rather than the business need. This can cause many issues, and is something DevOps tries to address. Understanding the business strategy, goals and priorities is essential to DevOps, helps drive and easily trainable. A ‘big picture view’ helps everyone collaborate on common objectives to deliver high-value business outcomes – a key tenet of DevOps
- Workplace history – “an appreciation for history, both technical and organizational”* will help staff understand the critical antecedents of DevOps, so they can internalize its principles not just rote learn its actions. For example, understanding hierarchical and network structures, why we adopted open work environments (and why it hasn’t always worked), and the antecedents of DevOps in things like The Toyota Way will help staff not just to act predictably in known circumstances, but adapt appropriately to new ones. (*Thanks to @garethr for input on this!)
Process Skills
- Agile development – it may be possible to take a DevOps approach in a waterfall environment, but it is almost definitely less effective. DevOps arose out of the Agile movement, and they pair so well that it is sometimes referred to as ‘agile for infrastructure.’ Teaching on one or more specific agile approaches (Scrum, Kanban, Kaizen, etc.) will give staff an approach and mindset informed by agile practices to help teams work together to improve flow, delivery and quality
- Lean approaches – ‘lean’ theories born in the manufacturing world (see ‘history’ above) give a pragmatic foundation for applied DevOps, not just new-age ideals. Concepts like Just-In-Time, Toyota Production System, Design for Manufacture, Theories of Constraint and Waste can be learned from original texts, courseware and many business courses. Some are also revised in modern IT-specific texts like The Phoenix Project or Implementing Lean Software Development
- Process reengineering – DevOps is as much about refining and improving ‘flow’ in the SDLC as it is about encouraging a sharing culture, so classic learning about how to effect change in business processes is invaluable to early stage DevOps adoption. Understanding how and why to analyze needs, identify problems, and effect change in software processes, organizational structures, teaming etc. is essential to DevOps and a long-established body of knowledge
Technology Skills
- Coding/scripting – in its current iteration there is a lot of focus on helping operators to understand coding languages; and teaching developers to use script-driven operations tools. From JavaScript (eek!) to C# or .NET, any coding or scripting skills will help both dev and ops to have empathy for each other’s jobs, and help to develop the elusive ‘T-shaped people’ that are so well-suited to a DevOps approach
- IT Automation – Enterprise DevOps especially will likely involve (require?) a raft of technologies in an automated tool chain. Because DevOps is concerned with end-to-end flow, such skills need to cover the whole SDLC. Look to provide training in Portfolio Management, Agile Project Management, Source Code Management, Version Control, Test Automation, Test Data Management, Service Virtualization, Continuous Integration, Release Automation, Cloud Provisioning, Configuration Management, Process Automation, Performance Monitoring and Event Management, whether through formal training or informal knowledge transfer
- Workflow mapping – smaller organizations might get away with pen and paper, or even a whiteboard/flipchart, but to document, share, analyze and rationalize the SDLC for large, complex, enterprise applications, you will need to learn to use workflow mapping tools. This will allow team members across the org (and the world) to take ownership of the end-to-end process, and start to collaborate on continual improvement
This is of course a (very) short list, but should give you a starting point for developing essential skills for enterprise DevOps practitioners. As always, please feel free to drop a comment and tell me what I missed, what is more important, or even what I got wrong. I am always interested in discussing ideas and learning new things!
January 5, 2015
Software Defined Data Centers Enable True DevOps

I have been talking a lot recently about the bleeding edge technologies that are offloading the complexity of DevOps management, and software quality. My last post on service virtualization is the latest example. Not lets talk about the software defined data centers. A dense topic, but a massive leap into automating, and unshackling a previously immutable component in the software delivery pipeline.

(more…)

December 17, 2014
You Might Already be Doing DevOps in the Software-Defined Data Center
I was out reading the Internet and came across a report from EMA (Enterprise Management Associates) regarding the state of the Software-Defined Data Center (SDDC) in 2014. After perusing the data and highlights, I was surprised (and yet should not have been) to find so much DevOps-related content and concepts within. Neither should I have been surprised to find significant mention of software-defined networking (SDN). It makes sense, in a puzzle-fitting-together kind of way, that SDDC comprises software-defined operations and software-defined networks (and probably software-defined storage but it’s too early in the day for me to contemplate that).

In any case, a significant percentage of organizations take advantage (today) of software-defined operations and networking, based on the report:

Which of the following technologies, structures or processes does your organization take advantage of?

4. Cross-functional processes to orchestrate provisioning and management of storage, network and server resources (57%)
5. Solution for server administrators to provision their own storage volumes (56%)
6. Continuous/centralized capacity management for physical, virtual and cloud resources (55%)
9. Policy-based automation of infrastructure for routine adjustments without human intervention (50%)
10. Software Defined Networking (virtual overlay network) (48%)
11. Software Defined Networking (separated control plane from delivery plane) (46%)
13. APIs for developers to provision their own app environments (servers, network and storage) (42%)
14. Configuration management solutions (Puppet, Opscode Chef, SaltStack, ServiceMesh, etc.) (41%)

More telling, perhaps, of how critical DevOps is to enabling the SDDC is the emphasis put on not just automation but on process. When asked what respondents believed were the “most important aspects of the Software Defined Data Center”, number 2 and 3 focused on deployment and automation of applications and infrastructure:

Best-practice, repeatable configurations of software and infrastructure for workload deployment (46%)

Orchestration and automation to easily deploy applications across silos (44%)

In case you weren’t entirely convinced, yet, “operational analytics” (we might call it “measurement” or “metrics” here in DevOps land) came in number four with a respectable 42% of respondents.

There’s more in the report, some less relevant but for the most part, reading this SDDC report left me with a decidedly DevOps after taste. Which was kind of a minty chocolate coffee taste, in case you were wondering.

The concepts typically associated with DevOps are not necessarily peculiar to DevOps or SDN. They’re generally part of a larger trend to operationalize all the things: the network, the storage, the compute, the security. The business goals of SDDC are strikingly similar to those promoted by DevOps and SDN – reducing risk, lowering opex, improving stability and time to market. The collaboration through creation of interfaces designed to promote repeatable, consistent (and measurable) handoffs between groups is present and looms as large in SDDC as it does in DevOps.

The point is that DevOps may, in fact, be in the adoption process right now under the guise of another name in an organization near you – or around you. If you hear someone saying software-defined something, check it out. You may be surprised to find out that someone has snuck in DevOps through another door, under a different name.
December 10, 2014
Log Analysis, or Log Hoarding

Let’s take a stroll down memory lane to remember the beginning of web application era: when a client had a problem, it called the support team to complain about the service failure or bug, and a customer support team would have written an incident report and forward it to the operations team, and then the operations team would examine it, mainly by looking at the logs with whatever helpful information they had from the customer.

(more…)

December 5, 2014
3 Tips to Shape Human Behaviors and Achieve Your DevOps Goals

DevOps raises many questions around processes and technologies, but it is important to remember that people are the essential piece that makes DevOps work. Since my post on Generalists vs. Specialists here on devopsy.kinsta.cloud, I have had many questions about shaping human behaviors, like this one:

Q. How can I help my team build up the attitudes and behaviors we need for our DevOps team?

In an industry often dominated by technical advancements, flashy applications and an ever-changing “next big thing,” it’s probably not surprising that the human aspects behind them usually fly under the radar. That is changing with DevOps, but there is a need for prescriptive advice on how to encourage a ‘DevOps attitude.’

This question then is typical of many looking for specific steps to help shape the human element of DevOps. So here are three approaches to help you encourage DevOps behaviors to be successful.

1. Connect Individual Job Duties to Higher-level Business Processes and Goals

In traditional environments, staff are often only concerned with their silo, not the overall process. They may fulfil their duties within their silos – writing code, testing release, maintaining stability – without ensuring the whole process contributes to the ultimate business goal, which is really the whole point.

By contrast, DevOps treats the SDLC as a value chain in which discrete activities (designing, coding, testing, etc.) occur in a complementary fashion to add value to the final deliverable – a production application. Traditional value chains have taught us that optimizing at the individual activity level can only get you so far – true evolution happens when you optimize at a higher, end-to-end process level.

I have posted before about encouraging a ‘big picture’ view of enterprise DevOps, but sometimes this is not enough. To take this a step further, you should directly connect the job duties of each team and each individual to the business goals, and hold them accountable to hit these goals.

2. Update Compensation Plans so They Align with Your DevOps Strategy

Speaking of accountability, one of the best ways to shape staff behaviors is to align rewards with desired end-to-end goals. Tying compensation to the entire team’s ability to accelerate delivery of high quality services, each individual will bear responsibility for all aspects of the SDLC. Not only does this provide ample incentive to embrace change, but it also gives staff a clear direction and specific goals.

This contrasts with a silo-based approach with, for example, a developer rewarded only for release speed, so they pump out code as fast as they can, regardless of defects; or an operations silo rewarded solely for stability, which encourages them to delay release in case new code breaks something.

Of course, pay is not the only compensation that motivates great dev and ops teams. So don’t forget other rewards, like training, conference tickets, new projects, team activities, or new responsibilities.

3. Technologies and Tools Will Help DevOps Staff Excel

When trying to model behaviors, it is important to remember that technology can help. For example, if your goal in adopting DevOps is to compress software delivery to meet a shorter timeline, you can’t just expect people to work harder, faster, and/or longer; you’ll need to help them with shared technologies that let your people work together better and smarter, not just harder.

For example, service virtualization relieves the need to build up physical test environments for every new code release, so dev and QA can build better code, test more, and improve quality. Release automation relieves of the need to manually release new code into production, so development and operations can focus on improving code quality and architecting for scale. Plus, both teams end up going faster, with fewer errors cause by human intervention.

Beyond specific tool selection, make sure your entire DevOps team is trained on their use, so they can all contribute by working smarter and better to achieve the company’s goals across their silos. This cross-skilling and shared responsibility helps to ensure the collaboration, communication, and integration of people that is an essential part of a DevOps approach.

December 2, 2014
DevOps: As critical for the Systems of Record as for the Systems of Engagement

There is a lot of talk about DevOps, and how it improves the process of delivering business value. Much of the discussion of DevOps has been focused on web based companies such as Facebook, or the mobile and distributed development teams. But DevOps principles apply just as well to the traditional Systems of Record, z/OS applications.   Many of these applications have been around for a long time and have very mature development and deployment processes. These processes include the requirements for separation of duties and audit tracking. Over the years these processes have developed into lengthy procedures, to be comprehensive, the net effect of this has been to reduce the number and frequency of the deployments to reduce risk. However, there is a better way.

In the recent blog posting by Ashok Reddy he talked about the 8 critical DevOps Practices: innovate, deliver, repeat. All of these are as applicable to z/OS applications as any other, for this blog I want to focus on just a few of the practices, Loosely Coupled Architecture, Automate Testing using APIs, Transparency and Minimize hand-offs, Maximize flow.

DevOps is about bringing the entire organization together, including Development and Operations, to more efficiently deliver the business value. The practices of “Transparency” and “Minimize hand-off, Maximize flow” go to the core concepts of the people aspects of DevOps i.e., integrating the organization.   By breaking down the barriers between the organizations, people can work together to accomplish the business goals more quickly. This does not necessarily mean actually changing the organizational structure, but it does mean having the organizational structures work together as cross functional teams.

One example would be the monitoring and optimization practices. These are generally done by Operations after the applications are deployed into production. However, if instead Operations and Development worked together in the early part of development cycle to monitor and optimize the application using the same capabilities that will be used in production any issues can be addressed much earlier in the cycle. This also helps both teams learn what is required to monitor and manage the application long before it is ever deployed to production. In many z/OS environments today, the same infrastructure is already available in the test environments, but it is seldom used.

A second example is to have Operations define the deployment automation such that it can be done by Development in early stages and turned over in later stages. This ensures continued testing of the deployment capability and a validation that by the time the deployment is done in production; the deployment process itself will be well tested. Through this integration of Development and Operations you remove the hand off that currently happens only at the final stage just before production deployment.

The practice of loosely coupled architecture is key when building multi-platform applications. Having clear interface definitions between the different parts of the application is essential of a loosely coupled architecture. It is easier to allow the capability to build independently, tested at the interface level and then brought together when the parts are ready. By defining clear interfaces between application components and properly handling forward and backward compatibility, there is less of a requirement for coordinated simultaneous deployments. This allows teams to be less dependent on other parts of the application during the development process, and allows for easier automated testing.

The practice of Automate testing is critical to any DevOps transformation. It provides the capability to improve the speed of delivery while reducing risk. Moving to agile development practices while still requiring people to perform manual tests, will not allow the quick iteration on the capability. Even for existing applications you can generate interface tests to begin to build up automated regression test cases. Automated tests can be generated based on interface definitions such as a JSON schema or a COBOL copybook for new development. The increased focus on testing the interfaces early helps reduce the integration problems generally found late in the development cycle.

These are just a few of the key practices of DevOps but hopefully they have started to demonstrate how DevOps is as applicable to the Systems of Record on z/OS as it is to Systems of Engagement.   To learn more read the best practices for a DevOps approach with IBM System z whitepaper or watch the replay of the November 20, IBM DevOps Symposium webcast.

About the Author:

Rosalind Radcliffe is a Distinguished Engineer within the IBM Rational organization. She is Chief Architect for CLM and DevOps. She is responsible for driving the DevOps for multi-platform architecture. This includes System z and Power system. In addition she is responsible for the architecture for the Collaborative Management capability for Enterprise solutions. This includes UrbanCode Deploy and Rational Team Concert’s support for standard Mainframe development activities.

She is a member of the IBM Academy of Technology and a Master Inventor. Prior to Rational, she was in Tivoli responsible for the SOA Management Strategy for IBM.

December 2, 2014
Infrastructure Automation and API Taxes

That automation is one of the critical components of DevOps is apparent in numerous surveys and studies that focus on the benefits organizations have realized from implementing the approach across operational groups. Automation itself starts with (or should start with) a comprehensive API. That means infrastructure – network and application focused – needs to expose via an API the myriad configuration options it requires as well as optional features it offers.

It is through these APIs, after all, that integration between devices and systems and across operational groups occurs. The much vaunted SDN or cloud “ecosystem” is really a euphemism for pre-packaged and validated integration. Integration that occurs via an API.

These same APIs are available to everyone, of course, and lay a foundation to operationalize app deployments by automating the various provisioning and configuration tasks required to move an app from dev to production.

APIs allow for fine-grained automation and orchestration, with each and every knob, button and slider option available to be flipped, switched or turned. The more features and functions possible, the more buttons and knobs and sliders there are to manipulate, figuratively speaking.

Each and every one of those calls to do so needs to be carefully managed. Exceptions happen, errors occur, and any script or tool ought to carefully validate that each and every one of those calls has been successful. Which is going to take a lot of code. Code that itself will introduce the possibility of errors and require maintenance and reviews and all that goes along with good development practices. Code that will also impact the time required to execute. Given that most APIs are RESTful and require invocation via standard HTTP exchanges, each and every API call incurs time to send, time to execute, and time to receive a response. The overhead is basically an API tax; for every API call you invoke, you’re paying with time… and more time.

Martin Fowler touches on this in his post “Microservices and the First Law of Distributed Objects“:

The consequence of this difference is that your guidelines for APIs are different. In process calls can be fine-grained, if you want 100 product prices and availabilities, you can happily make 100 calls to your product price function and another 100 for the availabilities. But if that function is a remote call, you’re usually better off to batch all that into a single call that asks for all 100 prices and availabilities in one go.

Thus for sufficiently complex systems another option is needed: templates. Templates do not replace APIs, but rather provide an additional and far more compact method of accomplishing the same tasks automatically, but without the overhead imposed by highly granular sets of API calls. Templates encapsulate a configuration; codifying the settings for a variety of knobs, buttons and sliders into a single configuration artifact. In a fine-grained API-base integration, each of those settings must be maintained somewhere external to the automation script or system. Each API call will include one (or maybe two) of those variables as read from some file or system that maintains the application-specific set of data. This introduces many potential points of failure. Whether file or database, variables must be retrieved before being associated with an API call and then transmitted to the receiving device. Errors may occur on read, on format, or on transmission.

In contrast, if all the variables exist as a single, validated configuration template artifact, it can then be sent, as a single entity, via an API call to the device or service in question. The number of potential points of failure is effectively reduced to read/retrieve and on transmission. This greatly simplifies the process as well as reduces the time it takes to actually execute the configuration of the target device or service.

In addition to simplifying integration by reducing the provisioning and configuration tasks from potentially hundreds of API calls down to a small set of calls, this has the benefit of fitting much easier into an infrastructure as code strategy, where common configurations are treated as artifacts and stored in repositories much like its application counterparts.

There is an inflection point at which it becomes advantageous to use a template-based approach over individual API calls. That point occurs before the scripts driving the API-based automation become as complex as an application and thus bring with it associated issues like error rates, time spent troubleshooting and maintainability.

A template-based approach simplifies upstream workloads and integration as well as discrete automation scripts by reducing the set of variables required to just a few – usually those dependent on network-specific values such as IP addresses and network segmentation membership (tags or ids representing VLAN, VXLAN, NVGRE, etc…).

This further ensures a consistency (and in turn results in greater stability of the underlying infrastructure) in app deployments.

APIs are a good thing. They’re a key enabler of software-defined architectures like SDDC, cloud and SDN. But API-enabling infrastructure doesn’t necessarily mean only on a checkbox and radio-button basis. That can be valuable but it can also lead to integration efforts that are just as complex (or more so) than their manual counterparts. A template or policy-based (application-driven) approach coupled with an API through which to deliver and execute such constructs results in a much cleaner, more consistent and stable means of integrating provisioning processes into the greater software-defined architecture.

November 20, 2014