TOGAF, a framework for architecture from Open Group, defines the data management principles. We can go into  them being complete or not the only principles arguments, or why TOGAF is not your favorite framework; but, that won't be the focus of this discussion.

These principles as listed are:-

1. Data is asset
2. Data is shared
3. Data is accessible
4. Data trustee
5. Common Vocabulary & Data Definitions
6. Data security

and, very thought out original definitions can be found at Data Principles

I find it very apropos that they mention the first three to be linked. For IT management:-

1. Data is asset. And for IT management it includes at least the following:-
   • All SDLC artifacts, from charters, roadmaps, plans, to code, to standards.
   • Customization of any existing frameworks, e.g. CMM, RUP, TOGAF, PRINCE2, ITIL, etc. if any, or if any is followed as is.
   • Various environment components(listed under NETWORK in the ZACHMAN framework) for SDLC, up to and including Production.
   • Cost of hardware, software, cost allocation models(capex, opex, depreciation, etc.), budgets.
   • All these are valuable, therefore, by accounting standards, assets; and, you have paid for them and their value cycle would vary from their cost capitalization/expensing/depreciation models.
2. Data is shared, the standard explains it really well, but the most important thing to bring up here would be the timeliness for sharing this data.
3. Data is accessible to users to perform their jobs.

Now the link for these is kind of obvious, may be the second and third could have been combined, how could one share without making it accessible? But, I digress, into splitting semantic hair…

The obvious conflict comes from application of the "Data security" principle. Which, needless to say, is very important when all the excitement is around security breaches leading to "identity theft crisis", election rigging, fake news, and what not…

But, all the politicians, have known this since the ages bygone… that "securing" information is the most important aspect. And, I did not bring in "politician" into conversation in vain. Politicians who divide and rule, as opposed to leaders. Leaders get the things done. And, the leaders who get the things done economically, while keeping the trust/well being of the people around. Economically, does not mean miserly; that, again is the ruse of "politicians" who would use the latter as a way to mislead and thereby to divide.

So, if you are the decision making leader, and want to be "the architect" of success for your organization, you know that you have a lot of variables in the equation, and what you are attempting at any given time is to optimize a multi-variate equation, maybe even a bit complex than the equations used by rocket scientists in fluid dynamics. Don't let the single point detractors take you away from that. Your followers already know that. And, if you are a follower know all these details to decide who should be your leader(s).

Going back to "data security" it is a very important feature, but don't let it get in the way of equally important triumvirate of data principles that it is "an asset",  "shared" and "accessible". It is not the first and foremost principle but there for support because of the other three principles. So, go ahead and architect your team's success, securely!

Practice self study, to commune with your chosen divinity.
— Patanjali, Yogasutras II.4

There are plenty of analogies you may have come across when people describe how to build teams that are able to deliver things way beyond anybody's expectations, in business world. We all get enamored by various performing arts/sports activities, as they don't tend to be as mundane as the world of business(Well, we haven't asked the players, but that would be digressing). One of these analogies often used is from the sports world where coaches/managers pick a star player, say a Michael Jordan, and then align rest of the team for supporting this player by being a very effective role players. How well has this model served the business? I have no study to quote for its effectiveness. But, I was wondering about something in my other blog and thought that there may be something lacking, that could make us too excited, and, that we could supplement this approach with, something... e.g. by replicating it... well someone guiding the basketball team, someone else say a football team...

Well most of the product development growth for this product set seems to have come from hardware side, and, then they got around to doing the software development(protocols, specifically). So "a star" from hardware side was supported by role players from software side, but a "a star" from software side from the get go would have delivered so much more value, so much sooner to the users that find this product useful or even exciting for solving their problems. Just a thought… your thoughts are welcome.