Want your developers to be agile? Then standardize your environment!
by Gregory Levine
I 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):
- /n – a global online directory
- Session Manager – single sign-on and access to all your application, TSO, and development sessions.
- Cross platform global job scheduler
- Global email (I still miss APL–Mail)
- Reference-Table – a self–service database table provisioning solution for developers.
Low Technical Debt (Technical Debt is a result of repeatedly postponing important
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
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:
- Limited Mobility – Try moving resources between different dev teams. Very difficult due to
steep learning curve.
- Low Developer Productivity – Limited reuse. Long lead times to provision required platforms. Difficult
to integrate applications. Data inconsistency/reconciliation challenges. Lack of architectural standards.
- High CapEx and OpEx
- Limited Shared Services – Low utilization and inefficient use of technology resources
- Policies – Difficult to enforce
- DevOps Challenges – Minimal automation, orchestration, monitoring/alerting, etc. Lack of respect and
teamwork between Dev and Infrastructure teams.
- Security Challenges
- Long Resolution Times – Difficult to troubleshoot problems due to complex non–standard IT environment.
- Low Associate Engagement
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:
- Can you justify the ROI?
- What is the impact to CapEx and OpEx?
- Is overall complexity increased?
- Do you have a plan to retire the legacy solution?
- Why can‘t an existing solution be used?
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:
- Goals for IT simplification/optimization and the target environments
- Disinvestment programs with clear understanding of financial impact (benefits!)
- IT Service Management - Leverage the ITIL framework to implement the Plan/Build/Run processes for IT Services
- DevOps Strategy - Bridge processes/cultures between Agile Developers and Infrastructure teams to deliver world
- Cloud Blueprint – maximize your ROI for public Cloud services (cost, service levels, productivity,
Contact us for a no obligation consultation.