Technology Management Revolution

New approaches for IT governance.


Adapted from “SaaC, CaaC Software Governance Strategies”.

Typically, a company that relies some or most of its business processes and assets on software products or services usually counts on a set of proprietary software artifacts and solutions; which in turn are often supported by a mix of open-source offers and commercial third-party products. Ideally, such valuable, sensitive and critical software assets should be subjected to periodical, systematic and formalized assessment, in order to monitor and ensure its overall quality. Besides, such software should also be designed – from the beginning – to last stable and “healthy”; due to a coherent and effective governance strategy, driven by the appliance and enforcement of the most relevant patterns, standards, rules and guidelines.

In thesis, the natural outcome of such diligent management approach should be a well-defined and well-structured set of related, independent and collaborative software artifacts; which, along with its supporting assets, could be positioned as the company’s software portfolio (CSP). This ideal governance style would naturally lead to the best of the worlds: ease to maintain, reuse and enhance existing software; easy to introduce and integrate new software assets to the company’s landscape; along with optimized time to market (TTM), return on investment (ROI), total cost of ownership (TCO), and so on. Unfortunately, nowadays that’s seldom or never the case.

So, let’s consider some business strategies that actually could lead us this way, through the “right path”.

ITaaC – IT as a Company

An ideal software application or solution should be designed, developed and maintained according to the currently well-known and widely-accepted best practices, policies, patterns, standards and guidelines. Software principles should be periodically reviewed and, whenever possible, automatically re-enforced. Software quality should always be closely monitored; also in a formal, systematic way. Customers (or clients) and business analysts should actively take part in each software process, from development to assessment, to maintenance, to retirement/evolution. Besides, the governance of each software development project should – from day one – assess software as the company itself, along with its current business strategies.

Considering some annual company’s board meeting, and apply the same kind of questions, or CONCERNS, like:

  • What are our goals, regarding this project, for the next year (given its current status, context and so on)? And for the next 2, 3, 5 years?
  • What are exactly the actual need, relevance and value of this project? And how will we assess and measure them?
  • Are the project’s goals feasible? If so, what strategies, policies, constraints, patterns and standards should be applied? And how will they be enforced, assured and monitored?
  • How should this software be positioned into the overall company’s software assets (portfolio)? In what context it fits? With what other assets and/or strategies will it relate to and/or depend on?
  • Are there some similar or contradictory initiatives currently in place?
  • Have we ever tried something like this before? If so, what were the results then? Are there some other “learned lessons” that should be also considered?
  • Are there some other alternatives? If so, what are their pros and cons?
  • When and how this initiative and its outcomes will be measured and evaluated? What will be its success and failure metrics and rules?
  • What contingency and mitigation plans, strategies and procedures will be required? Are they already in place, fully tested and operational?
  • How does this project depend on, impact on and/or relate to other assets, currently in place? What’s needed to assure it won’t mess anything up? How and when will this be enforced?

Moreover, as opposed to their company’s counterparts, software projects’ governance strategies, processes, goals, rules and policies should be public, widely spread and well known. Each and every stakeholder should know, in details, how does the company position, value and support the software s/he’s dealing with.

From the design perspective, I actually envision software growing up from POCO, N-Layered, command-query, service-and-functional-oriented patterns; even when these patterns are not apparently required, at first. Then, with such architectural foundation in place, we would extend, enhance and enrich its features; in a modularized, prototyped, incremental, iterative, test-driven and integrated way.

[ Next: Some fundamental guidelines ]

Complete text

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: