by Gregory LevineI never knew how good I had it as an application programmer at Morgan Stanley (MS) in the 1980‘s. A long overdue acknowledgement to Scott Abbey and his leadership team for creating an environment that was decades ahead of its time. Terms like agile, low technical debt, developer mobility, DevOps, etc. were not used back then, but they existed in the house that Scott built.
One could describe the MS environment circa 1985 as heavily standardized with respect to architectural frameworks, developer toolkit, common functions and utilities, authoritative data sources, no application redundancy, and shared infrastructure and platform services. And like most of Wall St., we had to support very demanding Equity and Fixed Income businesses that expected quick development turnaround times. Suffice to say, a very high-pressured environment and many long hours. But when I think about it, our challenge was in understanding the business requirements and not worrying about developing, integrating, testing, provisioning, orchestrating, and deploying product.
As I say, we didn‘t realize how good we had it - a mean lean IT environment with highly productive and agile developers. In many ways, the environment that Scott & co created achieved all of the things that most IT shops now dream of:
Innovative: You wouldn‘t think a heavily standardized IT environment would be conducive to an innovative culture, but it was. People rotated around a lot and contributed new perspectives to their teams. Existing building blocks were leveraged in ways never contemplated. New solutions were introduced that provided incremental benefits. True R&D and experimentation were encouraged to obtain step – rate improvements. The reason we were innovative was because we had time to be innovative. We did not have to waste time figuring out how to develop, integrate, test, and deploy. I remember joining MS and being amazed by some of the homegrown innovative solutions (remember this was back in the 1980‘s):
Low Technical Debt (Technical Debt is a result of repeatedly postponing important maintenance/re–engineering/migration activities): Many shops are not focusing enough time on simplifying the environment, decommissioning legacy applications, optimization, and reducing complexity. End result, Technical Debt is increasing at an accelerating rate, and the behavior/incentives/priorities/focus have not changed to reduce it.
By the way, according to recent industry research, guess which IT shops are the most productive, cost efficient, agile, and have the highest customer satisfaction? The ones with low technical debt! MS in the 1980‘s had one developer toolkit, one library of common functions (e.g., interest calc utility), authoritative source of standing data, one trade file, one position & balance database, etc. which were to used to create the legendary and powerful TAPS ecosystem of applications. As a developer, the speed and ease to respond to new business requests was phenomenal; Calculate and post daily interest P&L for a new type of discount bond, no problem (read position DB, access product DB for additional standing data, call interest calc, post to journal DB) – coded and unit tested in 30 minutes. Need to understand exposure to a product across all trading accounts, no problem. 5 minutes. We reeked of productivity!!!
DevOps (Gartner definition - DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology – especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.):
We really did achieve the Holy Grail of DevOps (which is NoOps!!!). Massive amounts of automation (migrating apps from dev-to-staging-to-prod, job scheduling, adhoc processing, report generation, well documented API‘s and record types, etc.), performance management, and application instrumentation/tooling resulted in fast delivery of high quality products. Developers rarely had to contact and wait on Infrastructure teams for anything, and could therefore concentrate on developing.
IT Optimization: Developer and Infrastructure teams were incentivized to save. As a developer, I remember one of my objectives every year was to save 2x my salary in IT costs - CPU, DASD (storage), Tape, Print, Fiche (remember that one?), Database calls, CICS transactions. And teams worked together to optimize the environment. The Database team would work with developers to optimize Adabas transactions and set up proper purge routines. IT Ops designed and built automation to identify and archive/delete unreferenced application files. For some reason we just knew that building apps, infrastructure, and platforms that were highly optimized would translate to improved top–line and bottom–line growth for the firm.
Governance: Because of the above items, it was easy to establish and enforce policies, standards, and procedures. And people knew not to violate or else. The environment was locked down, and you had to use the approved tools or follow a specific process to complete your tasks, which were audited along the way. It literally only took seconds to determine who/what/when updated a database, or if any changes were made to an application or platform.
Mobility: Again, because of the above, there was no technology learning curve when developers rotated around the organization. Sure, they had to learn about the business side of their new application, but no technology re-training/re–tooling. Developers hit the ground running when they joined a new team. For Scott & co., this made it extremely easy to move resources around to meet new business demand/priorities.
Many of us have worked in environments with every technology known to man, no common dev tool kit, redundant data with no clear authoritative source, growing application inventory (with many apps doing the same thing), and an overall belief that in order to be agile and nimble requires extreme flexibility with respect to allowing new solutions. Let me repeat that last item again: An overall belief that constantly introducing new solutions creates an agile and nimble organization (and anyone trying to encourage reuse or enforce standards is labeled as inflexible and inhibiting the organization’s ability to be agile). If your IT leaders believe this, RUN!
Having lived on both sides of the fence, I‘ll take the MS approach of the 80‘s in order to avoid the mess that exists in many IT shops today:
Time for some motherhood and apple-pie: I believe most would agree with the notion that an agile environment is easier to achieve by adopting enterprise architecture frameworks, processes, services, and technology standards.
Why haven‘t we standardized?
The answer, all too often, is due to shortsightedness and IT religion. Overtime, new IT solutions are introduced due to new hires, acquisitions, and doing things the quick and dirty way. If left unchecked, you end up with a very heterogeneous IT environment (architectures, technology, skills, procedures, processes, data, apps, etc.). Unfortunately, due to IT religious beliefs (AIX vs SunOS vs HPUnix, Java vs .Net vs C, JBOSS vs WebSphere vs WebLogic, Oracle vs Sybase vs SQLSever vs DB2, multiple competing architectural frameworks, etc.), many IT leaders fail to look beyond the benefits of a uniform organization and instead focus on their own domain and utilize what they know or what they believe to be superior.
Time to abandon our myopic behavior, and do what‘s right for the greater good. IT leaders need to either drive consensus or make the executive decisions to achieve a more homogeneous IT environment. We will never achieve 100% homogeneity, for various legitimate reasons, but it should be the goal. This does not mean you never innovate, experiment, or implement new solutions. What it does mean is that you do so with eyes wide open. i.e., understand the implications of increasing technical debt:
IT leaders should also ensure that application and infrastructure roadmaps include items to drive standardization and reduce debt.
Hararei can help companies create agile and productive teams. Starting with an assessment of their environment, we then work with the customer to identify and quantify the opportunities that will provide the greatest returns. We help to establish:
Contact us for a no obligation consultation.
Original Article
Hararei Blog