The ControlTier Manifesto (a work in progress)

The word manifesto may be a bit too overloaded, but we've always hated the meaningless content of corporate mission statements. So here it is:

The ControlTier Manifesto

Who we are...

1. We are a unique combination of development and operational experts that have lived in each others' shoes. With a deep understanding of each others problems and requirements, we have set out to streamline and automate operations across development, QA, and production environments.

2. We are developers and administrators who are determined to provide services that give our customers a competitive advantage by enabling them to achieve operational excellence and improved margins.


What we do...

1. We are our customers automation partners. We act as their independent agents of change focused on improving the efficiency of the application lifecycle through streamlined processes and extensive automation. We don't just provide the missing tools, we provide the expertise and accumulated best practices needed to successfully implement the tools and bridge the gaps between the various groups involved with the application lifecycle.

2. We develop and implement model-driven toolchains that automate build, deployment, configuration, and management activities. These toolchains implement an enterprise's specific processes, are reusable across all environments, are built to be flexible and extensible, and are built on open source tools and frameworks.


Further, we believe...

1. Build, deployment, and configuration activity happens all across the application lifecycle and impacts Development, QA, and Operations budgets. Too many talented and expensive technical resources, in every group, are being consumed by these non-value adding activities.

2. While acknowledging that writing source code has some elements of an artistic endeavor, the rest of the application lifecycle is a strict engineering endeavor and must be be expected to have the same level of widespread reliable automation and visibility that is found in traditional manufacturing operations.

3. The point of companies that operate software as a revenue producing service is to operate software as a revenue producing service. It is pointless for all software not to be "operations-ready" from the moment it is checked-in by developers. To enable operational readiness, all Development, QA, and Operations groups must be linked by a common automated build deployment framework.

3. All automation must pass the "two toss" test: If you throw any machine out of a window, can you automatically and instantly rebuild your service to a properly working state? If you toss any developer or admin out of a window, does your ability to deploy and maintain your service remain intact?

4. In order to be successfully adopted, automation frameworks must be available under a free Open Source license. Developers want open, transferrable skills to which they are free to apply in any manner, form, or frequency they see fit. Enterprises should be free to utilize, modify, or extend their automation (and its underlying framework) in any manner, form, or frequency they see fit. Traditional closed source licensing only places an unnecessary and burdensome "tax" on both individuals within the enterprise and the enterprise itself.