Staying with the Program Vision
I advise startup data companies. I try to put certain guardrails around the development to those features that will meet a certain criteria. The criteria is not that strange really when you think about it. The criteria is that it can be monetized – either short-term or long-term.
It’s nice to be visionary but too many feature sets are muddled with a desire for this abstract standard as opposed to solid answers to this one important criteria. I know features can be layers removed from license sales, but let’s string together a reasonable story.
Ultimately I just doubt those companies who don’t have this approach to developing a product will succeed. Just a dose of reality on this Spring morning.
I couldn’t help but think about the many features that companies have added to their analytics and data warehouse programs that also could not pass this test. While these programs may not be selling licenses and directly impacting company monetization that way, the programs have goals and development should contribute to that.
Architecture is important because it drives efficiency of the operation. Future features from the program that can be “monetized” in the sense of creating user value can be spun up much more quickly from an architected environment.
The concept of architecture, and many other aspects of a program, can be abused as well. It can go too far abstracted from user value. Only judgment can effectively reign in the unnecessary and keep the program aligned with its focus.
More often than not, architecture is not abused with volume – it’s not done enough. This is not true of some other associated programs that must be mentioned.
Data Governance needs its monetization too. I didn’t say data governance is bad, a waste, or anything like that. I just want data governance – actually everything – to see the manifestation of its work. In the case of data governance, that’s quality data in leverageable places. While a single system can be governed as well, if the data is leveragable, the governance efforts are magnified in their impact.
Such systems include master data management and the data warehouse. Both of these have, eventually, numerous users in the form of analysts and in systems impacted. For master data management, the subscribing systems will receive the high quality data.
The data warehouse will have numerous uses and probably numerous downstream data marts. Hence, the high leverage.
Data privacy, security, retention policies and tiering data storage are also important issues that data governance deals with. These are obviously necessary either to keep the program out of trouble or as decisions that obviously have to be made for architecture.
Metadata is another program area that can “take on a life of its own” outside of the program vision. Just watch it. We need metadata too, but we have a lot of work to do and ultimately need to keep focus. Don’t become enamored with your work to the point of not delivering a monetization.
This post was written as part of the IBM for Midsize Business program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet. I’ve been compensated to contribute to this program, but the opinions expressed in this post are my own and don’t necessarily represent IBM’s positions, strategies or opinions.