Service-orientation is inevitable when Technology is applied, but new service providers who deal with emerging technologies often struggle to build a reputation from scratch. This is more frequently a common constraint in technology entrepreneurship due to service-orientation as an emerging trend in high-value/high-tech business modeling… amidst many not-so-high-value/not-so-high-tech service-providers who make a bad name for Service at large (as they lag behind technology and continue delivering yesterday’s substandard service.) If service is delivered when and where a constraint is exploited, then the service provider becomes the constraint and enjoys the leverage.

If that guy up there was a Patent Troll he would be taking 101 or 280 probably…actually yeah he might be taking the golden gate bridge maybe the other way. Maybe he’s trolling for honeys on USENET or IRC. Maybe he’s on his way home from stealing some ideas from the guru of all Marina yupster intelligence. Hopefully the good folks at GoGrid won’t let this troll near their datacenter if he heads back. I can’t tell you whether or not a famous Giant was using steroids, but I can tell you that this is not a San Francisco Giant on steroids carrying a club instead of a bat… and I can tell you that collaboration is like competition on steroids.

Automation, hated as it may be by some (service-providers usually), removes the human component. Self-service provides many access to something less constrained that only few experts could access before. If you try to pump your own gas in Oregon, you may be advised by an attendant. If you try to pump your own beer at the pub… they reserve the right to refuse service to anyone.

Even the most product-focused constraint theorists agree that at minimum viability, any product contains at least one service component. The theory of constraints doesn’t stop at identifying a constraint, but goes much further in exploiting the constraint often through systematic means. It’s systemic, however, when a service provider becomes the constraint, because efficiency can be greatly reduced by a single bottleneck.

The pattern suggests that service providers themselves are often the constraint and targeted by innovative (yet amateur) constraint theorists who aim to take the incumbent service provider’s position, but are not high-attenders to the theory of constraints because they fail to practice disciplined exploitation of the constraint. Wannabe constraint theorists fail to scratch the surface of the theory of constraints when they position themselves in such a way that they become the constraint. Value sustainability is questionable where a service provider becomes the constraint. For inventions (by value standards) the constraint must be exploited and the cycle must repeat. It proves the time-line itelf, in all its linear glory, to be the ultimate (unexploitable) constraint. This is why the most loved project managers keep developers and other contributors off the critical path and work within only the transparent actual deadline… the only real deadline… the only deadline which is capable of killing everyone on a given project. Some say whoever’s holding the clock’s holding the keys, but they better be holding my keys if it’s on my clock this new year, because I’m going to need another drink and another deadline before the fog clears and the cloud is recognized as more than just smoke and mirrors.

In application / software development and other technology project lifecycles: to become the constraint is to become eventually obsolete… consistently. This is just one example of why planned obsolescence beats the unplanned alternative.

Constraint Exploitation Spirals as a Delivery Product for Immediate Cross-industrial Consumption and Consortium

The theory of constraints becomes even more interesting when it’s applied to open-source vs. software-as-a-service or DevOps methodologies vs. Design practices (constraint invention) or from a more generally abstract perspective: Nature vs. Nurture (DevOps applied to fields outside of software engineering such as business development / Biz DevOps) … other bastardizations follow, integrations evolve and chapters merge. Thoughts converge and in iteration constraints expire to evolve design practices within an actual framework of iterative methodologies which function as a spiral of threads into various fields of expertise and operation scale. At the constraint, the spiral is most tightly woven, but as it reaches endpoints in the periphery of the market, iterations unwind and loosen the coupling for lower attendance. This is a process by which service constraints may be woven and unraveled to produce value between what-is and what-could be. Reducing friction between what-is and what-could-be is the secret weapon DevOps methodologists are now bragging about in between sword fights over language or configuration management tool manufactions. The delivery mechanism empowers the inventor or innovator to design, architect, implement, or otherwise become part of a constraint which sells itself to a market governed by global open standards.

What is DevOps?

DevOps is the strategic intersection of technical quality assurance, technical operations, and development. In most implementations or attempts to achieve DevOps synergy, Development refers to innovative software engineering, but may also refer to other innovation such as creativity. The DevOps movement got rolling because people with a dedication to productivity became frustrated with tossing packages over the wall of confusion between Development and production operations.

Developers have a stake in the innovation game any time they are hired to be creative, artistic, or re-engineer that which could be improved upon. Those who are paid to do something new often find their interests in conflict with production operations engineers who are paid to operate within a reliable, proven framework. These production operators are members of a highly available infrastructure. DevOps solves this problem by crushing the wall of confusion with the hammer of integration, held by stakeholders in the environment of shared responsibilities. When changes are managed in such a way that there is shared responsibility for concept-proven, tested, quality assurance many benefits emerge. One benefit is that production engineers no longer have to re-hack the developer’s deliverable in a production environment. The production environment becomes adaptive to proven concepts within an ecosystem of collaboration. Collaboration is like competition on steroids, especially in the fields of shared interest where quality is upheld and orchestrated by multiple groups.

Quality assurance can be achieved through collaborative testing. Rolling back to a last known good configuration/implementation is much less necessary when it’s efficient to roll forward to a tested configuration/implementation. This is made possible by technology, of course. Technology is the study, practice, and pursuit of productivity through tools. A technologist seeks to invent tools or teach those around him the way to use a tool or tool-set. In a tightly integrated DevOps core with sustainable gravity, responsibility and tool-sets are shared among authoritative stakeholders in an iterative project. DevOps is much more than just an AGILE cat’s finesse. It’s the Chef’s best. Get Served.

Welcome to McDevOps may I take your order?

McDevOps is the Management of changing DevOps. Configuration management is nothing new or simple, but it becomes artistic without a framework for best practice automation. Here’s why:

Automation can only be profitable in situations where human error introduces significant risk or antiperformance. Antiperformance often exists in situations where a reverse engineer has re-invented a wheel which cannot possibly spin faster. Be advised, however, that it may be considered hasty speculation for a reverse-engineer to paint his or herself out of the Innovation picture in fear of could-be antiperformance. Innovation does indeed require both grit and grid. Let’s not overlook the problem of Semi-automation introducing risk when transparency is lost among service layers. Service-oriented Architecture is not resilient if foundations are simply service level agreements. Solid Service-oriented foundations are built from a lot more grit in the bricks.

Feedback looping, testing, dogfooding, metal and electricity create a fine mix and anything built from it becomes infrastructure, but perhaps only elastic provision can efficiently and effectively automate the process and balance the scale.

The design process never ends, which may seem counter-intuitive to the designer who is unfamiliar with iterative process momentum. Let me assure you that counter-intuition is key to innovation, especially in design practice. Iteration is often the seed of momentum, but many branches require many roots.

Quality may be challenging to control, but design principles make it very possible to contrive. Be aware that in some production environments, a tightly coupled or performance-oriented DevOps core may unfortunately exclude feedback at times, but should create a gravity of production insights from all three inner circles. Collaboration is like competition on steroids. The alternative is advancement along the production curve at the expense of innovative development and best practice designs as deliverables. In order to deliver cutting edge services, a service-oriented architect or Agile DevOps must bleed on the edge.

What framework will be designed as a platform for success in your sphere and how might the wheel spin faster, more efficiently, and more effectively?