Factory for Factories
Consistently Automating for Innovation
I like to envision software delivery automation as a factory for software, with centralized enterprise delivery automation acting as a factory for these factories. The objective of any factory is to produce something as quickly and efficiently as possible without compromising quality. The factory for factories — let’s call it a meta-factory — understands, at a very high level, what it takes to produce products of similar ilk. Specific variations of this product family and affiliated quality measures may differ, but the general process for creating them remains largely the same.
Let’s say we build vehicles…
A vehicle factory produces vehicles according to the objectives of a factory. The specifics vary, though the basic layout and premise of vehicle factories follow the same broad guidelines — raw materials go in one end and an operational vehicle comes out the other.
In the meta-factory that creates vehicle factories, each ‘factory’ it produces starts with basics production segments — an engine, chassis, tires, interior and exterior. Each segment may be more or less complex — or even unnecessary — depending on the vehicle produced.
If our vehicle factory is building…
When some clever R&D person decides they want to mass-produce solar-powered submarines, the vehicle meta-factory gets a call to make one vehicle factory with…
- Engine: Solar-powered electric engine with a LOT of batteries
- Chassis: Egg-shaped steel shell
- Tires: One big propeller
- Interior: A comfy seat near a 2" thick glass window
- Body: Awesome flames painted on the sides
After a few months, it becomes apparent that solar power isn’t selling so great and generating a lot of returns — so that segment gets replaced with hamster wheels (hamsters sold separately, of course). Oh well! At least the next time someone wants a solar-powered engine the meta-factory knows how to make that!
Hamsters!? I thought this post was about software development…
Mapped to the above, a software factory produces applications according to the objectives of a factory. The specifics vary, though factories that deliver software follow the same broad guidelines. Text and intellectual property go in one end, and an operational collection of functionality comes out the other. Each segment may be more or less complex — or even unnecessary — depending on our application.
(Sound familiar?)
In a meta-factory that creates software factories, each software ‘factory’ starts with some basic validation segments — configurable dependency/build/unit tests, functional testing, deployment, integration testing, and go-live. Each segment may be more or less complex — or even unnecessary — depending on the application being developed.
(Sound familiar?)
If we are building software…
When some clever developer decides they want to use Node.js, the software meta-factory gets a call to make one software factory with…
- Build: npm install and lint check
- Test: No-op functional test segment (maybe later, they say)
- Deploy: Deploy to QA environment
- Integration: Manual validations
- Go-Live: Release to production!
After a few months, the manual validations are replaced by automated tests when the manual validations are found to be too slow. Users also found that they can develop much faster when problems are identified sooner, so an automated functional test segment is added (we should have done this sooner, they say).
Decentralized ownership
In the examples above, the meta-factory is called upon to produce the specific functionality within the segments. Unfortunately this doesn’t scale well, as the number of factories increases the meta-factory becomes a bottleneck for the individual factories to innovate or respond to change quickly.
Spoon-feeding the specific segment functionality also creates a support challenge. The individual factory that is responsible for delivering the products doesn’t own the results of their segments because they didn’t create them! Fostering a You-Build-it-You-Own-It culture that extends to the specific segment functionality empowers the individual factories to control their own operations and allows the meta-factory to focus on delivering additional value to all factories.
Centralized added value
Now that there is a unified way to describe and develop segments, we can start to realize additional gains that this provides. Not only can we share similar or previously used segments with other factories, we can build in common functionality that applies to all segments and factories. Each segment could have built-in functionality that reports back problems, efficiency statistics and current status to a production dashboard so the meta-factory can identify places for improvement, regardless of the specific nature of the factory or segment. Centrally unified reporting, re-usable feature development and overall delivery visibility are some of the enumerable advantages a meta-factory can provide that individually created and managed snowflake factories may not.
You’ve gone too far…
As always there is a balance to strike. If the meta-factory is too broad it becomes less useful, on the other hand if you provide too much central opinionation it becomes too prescriptive and difficult to maintain.
Moral of the story
A broad and consistent process allows for individual innovation and ownership as well as central oversight and effective re-use. Also people like it.
DISCLOSURE STATEMENT: © 2019 Capital One. Opinions are those of the individual author. Unless noted otherwise in this post, Capital One is not affiliated with, nor endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are property of their respective owners.
