Commentary: A Draft Manifesto for State IT Modernization, Part 2

In Part 1 of this commentary, Rob Klopp addressed Guiding Principles as the first of three elements in his "Draft Manifesto for State IT Modernization." Today, he addresses two final concepts: Technology Guidelines and IT Staff Culture. (The use of "we" throughout is intended to convey that the manifesto is written in the voice of state IT.)

Technology Guidelines
The state recognizes that technology is rapidly changing, and we value the perspective offered by our commercial partners on the direction we might take. We will strive always to select buy-build options that represent current best practices and will avoid options that are built on technology that is one or two generations behind the times, regardless of the cost. In a rapidly changing technology market, we recognize the long-term cost of buying dated technology does not satisfy our obligation to provide the state with good value.

Providing the best value is not as easy as always picking the latest hot technology. We know that there is hot flash-in-the-pan technology that should be avoided. To strike the right balance, state IT will look to several key references to understand trends. When our vendor partners propose technology to us, these are the places we will look for confirmation, and these are the references we expect our partners to refer to when they work to convince us that they are offering modern technology.

In general, state IT will look for products that are trending upward and avoid technology that is flat or turning down.

Programming Languages
The state will utilize programming languages that can produce applications that follow the best practices outlined earlier: modular code that can be tested and profiled automatically and daily by a modern development environment (MDE) that follows the Twelve Factors, and that's capable of delivering cloud-native applications.

We will look at the following resources to determine which programming languages are popular enough and not losing popularity: Octoverse, Tiobe and PYPL.

We will further check to be sure there is an automated unit test capability, code profiling capability and the ability to deploy the language into a cloud-native application.

Databases
The trend in databases suggests that multiple specialized databases should be considered, rather than a single enterprise engine. As a result, vendors now offer relational database management systems (DBMS), key-value stores, document stores, graph DBMS, time-series DBMS, object-oriented DBMS, search engines and more. The use of open source databases such as PostgreSQL, MySQL and MariaDB (a “more” open version of MySQL) are on the rise.

State IT will look at surveys from sites like DB-Engines to identify trends and we suggest that our vendor partners check there, too.

Frameworks
Frameworks provide tools to help develop and deploy applications built using the languages and databases and other components mentioned above. Frameworks may provide tools to interactively design screens and to quickly deploy databases. They may help to integrate languages and databases and assist in deploying final products as containers. Frameworks may be built over comprehensive programming languages like Java or over succinct languages like JavaScript or Python. Commercial frameworks may bundle succinct proprietary languages with these other features into “low-code” frameworks. Open source frameworks generally bundle the same features for free.

There is one important fact to note regarding proprietary frameworks: They often bundle domain-specific modules that can be reused to good effect. This is the commercial version of borrowing open source modules. Assuming that the proprietary framework passes the modernization test — modular code that can be tested and profiled automatically and daily by an MDE that follows the Twelve Factors, and is capable of delivering cloud-native applications; and that the domain-specific modules fit the domain the state agency is working in — the state will strongly consider the cost-effectiveness of using a proprietary framework.

State IT recognizes that there is a very dynamic marketplace for frameworks. We will be cognizant of changes and listen to our vendor partners for ideas about how to leverage frameworks to maximize velocity and reduce costs.

Cloud-Native
Generally, we would refer vendors to the definitions available on the Internet around cloud-native concepts. Here is an abbreviated definition as a shortcut:

The state recognizes that the concept of cloud-native is rapidly advancing and changing. The simplest test we will ask is whether the application being proposed is elastic — that it's capable of automatically expanding the underlying infrastructure as compute, memory or storage demands increase, and that the infrastructure automatically contracts as demands decrease. In addition, we will ask if the pricing for elastic infrastructure allows the state to pay for what we use. Finally, a strong indicator of cloud-native computing is the ability for the application to run in a container.

An application is not automatically cloud-native if it runs off-premises in one or more virtual machines on a subscription.

The stronger the argument put forward for cloud-native computing by a vendor partner, the more likely state IT is to favor that vendor.

Other Sources
Several other sources provide data on software popularity:

The 2018 Stack Overflow survey can be found here.  

Statista also surveys the software market, with results found here.

IT Staff Culture
State business modernization will impact the state in a variety of positive ways. This section will describe the culture our vendor partners should expect to work in.

Get on With It
Agile methods let us build user stories quickly and get started. State IT will expect our vendor partners to keep up with us or to push us. We will get on with it and push to increase velocity with each subsequent product increment.

User-Centric Product Development and Quality
In the new culture, state IT is a service bureau that serves the various product owners in the department. Product owners build user stories and prioritize them into product increments. Product owners accept user stories as complete. The pace of acceptance is set by the program owners.

Further, state IT will strive to deliver quality products with each increment. There will be measurable indicators of performance with release criteria that is established by the business. If the quality is missing, the product will not be released. A 100-bug backlog will not be tolerated.

Continuous Improvement, Continuous Change
Change is a constant in IT, and the pace of change is accelerating. State IT will embrace change, and the IT staff will optimize to change instead of optimizing to a known set of expertise. The staff will be comfortable with multiple cloud providers, multiple databases and multiple programming languages, and will be happy to learn the next one when the time comes.

State IT will expect our vendor partners to change with us, to help us to change, even to push us. We will not hold you back.

Trust
State IT will trust our trusted vendor partners. When trust is gone, we will find a new partner. This trusted relationship will allow the state to focus on results and reduce the requirement to lean on contracts to get performance. This trusted relationship will let vendors work hard and produce results, knowing that results are what the state cares about.

Transparency
Transparency has been discussed in this paper. State IT will implement tools that transparently measure progress, velocity and quality. Transparency will create trust, as there is no place for either the state nor our partners to hide.

Accept Reasonable Risk
Software development cannot be made risk-free without slowing progress to a snail’s pace. The state will establish reasonable objectives, knowing that in any two-month product increment (PI), we may miss by a little. The other side is that with each PI, we will set some stretch goals and expect that sometimes we will make the stretch. Over time, a little miss here will be compensated for by a stretch there.

Learn
State IT will continuously change and improve, and this means that we will become a learning organization. State IT aspires to become expert and grow to the point where we can teach our vendor partners a thing or two. We will become self-reliant. We will give our staff a chance to learn, not just in classroom settings but in projects that expose staff to new technology and by allowing time to play with new tech.

Have Fun
All of this combined will make state IT smart and fun. We expect the state to become recognized as a leader in IT. In this way, we will attract smart staff and fun people.