It just won't, regardless of how hard you try to force him to do it.
Nevertheless some still keep trying & IT seems to excel in that idea. Yes, that's another post about scaling in IT, but this time I'm not going to write about overgrown projects (I already did it here), but about overgrown products.
The quest
Companies spend zillions of local dibs on never-ending unifications, migrations, mergers, consolidations - the goal is to have:
- one, huge, universal (hell-of-a-)system instead of many
- one skill-set instead of many
- one, integrated data perspective on whole business
etc.
Grow, Grow, Grow.
Merge, Merge, Merge.
Unify, Unify, Unify.
Doesn't work? Ok, so "we'll do it the agile way" (sigh). Needless to say, it barely ever ends well, if not accompanied by necessary changes in organization's culture & mindset.
What usually happens
- "Universal" systems that are built to fulfill several needs (with a clear intent of reducing costs & simplifying IT landscape) are the nests of technical debt, bloated with rushed, over-generalized abstractions born by mixing different contexts in a crooked way. Hard to maintain, hard to change, burdened with dependencies on everything around.
- Vast majority of wide-scale consolidation is one-off, waterfall projects (with all the consequences you hopefully realize without me being to explicit) - very few of Enterprise systems are truly modular (of course it stands completely opposite in their marketing materials ;P).
- Unifying skills, roles, technologies is so 90s. It's a product of ancient way of thinking that considers people as "resources" - they are supposed to be re-allocated & re-deployed freely like generic spare parts. Screw the "fit-for-the-purpose" principle, everything can be done using SQL Server & Visual Basic, forget the product ownership or building internal team's synergy (team is just a bunch of random resources sitting together at the moment, right?) ;P
- Huge data consolidations are even more funny. People can barely do anything sensible with small, few MB sets of data, but they don't even try, because the key is to have EVERYTHING within a (theoretical) reach. Obviously when they realize that everything comes for a price & so-called Big Data is rather "slow, unverifiable data with fuckin' huge inertia" it's already too late. The biggest irony is that usually there's merely any justification for this unusable crap anyway.
Been there. Done that. Cried a river.
What if ...
What would happen if you've tried it differently this one time ...
- Instead of constructing patchwork leviathans of IT systems, design & build ultra-light, coherent, decoupled IT products around services that bring actual value to your business. How to do that?
- cross out "big bang" from your vocabulary - only incremental, small, frequently deployed changes; don't frown, it IS possible in pretty much EVERY scenario - it just requires a significant shift in the ways of thinking & a lot of engineering discipline
- all integration via internal API based on open standards, under rigorous versioning policy
- what I'm doing here is not really advocating Microservices or any other buzzword, ... it's rather about proper domain(s) decomposition, which is something far more important & it's not only about services
- put maintenance as a transparent, distinguished element of budgeting -> there's no better incentive for decommissioning & technical debt control
- outsource everything what's out of your core domain (& most critical supporting domains) - don't customize stuff that won't make any actual difference on your business, adapt to industry standards in generic / supporting sub-domains
- get rid of all the crap that artificially binds your IT products & forces unnecessary dependencies - like ESBs, visual process orchestrators, humongous application servers, snowflake infrastructure on bare metal
- what I'm doing here is not really advocating Microservices or any other buzzword, ... it's rather about proper domain(s) decomposition, which is something far more important & it's not only about services
- Instead of scaling-up your company, out-scale it. How to do that?
- treat each IT product described above (& people who develop it, not only in terms of software development) as a sort of Lean Startup - semi-independent organizational unit that scales together with the product & serves internal services to the rest of the organization
- let them have their own standards, technologies, tools, practices, cadences & increments - but also make sure that they take the full accountability for their decisions (e.g.: "you build it, you run it")
- don't fetter them with manacles of policies & rules that were not meant to apply for them in particular, set the high-level meaningful goals (preferably with tangible metrics) instead of detailed (& insta-outdated) prescriptions
- Instead of merging contexts per force, make sure they are translatable (can be mapped) & abstractions do not leak between systems. How to do that?
- do only what's needed, nothing more - this applies to data as much as to code - e.g. having a massive cash-sink named Data Warehouse that has barely any use but the most simple P&L, balance & sales reports really doesn't make any sense (just because every company is expected to have an item of expenditure of this name ;P)
- don't design for re-use; re-use is a consequence of good design, but still - it's far, far less important than you think it is (as opposite to maintainability, clear ownership & controlled coupling)
- in a wide-spread, huge organizations do everything that's possible to shorten the communication / dependency paths, even if it means multiplying the capability (e.g. service) & creating some redundancy. Let them grow & develop separately (but encourage cross-unit collaboration of course) -> this may seem like multiplying the cost, but it spurs the agility & reduces inertia in local units
This blog post was somehow inspired by the article "Scale your product, not your Scrum" - by Cesario Ramos.
