Category Archives: Blog

Why do DBAs sit in a office corner and other IT’s best kept secrets….?

Leave a reply

censorship-610101_960_720

 

“If you want to keep a secret, you must also hide it from yourself. – George Orwell, 1984″ 

With no offence meant to DBA’s or other IT folks mentioned in this piece would like to put across a few of IT’s best kept secrets on the table. It is nice to have them as secrets but why bring it out. It might help someone somewhere to think about it and use this secret for their own good once they know it is a well guarded secret and getting around the secret is actually going to help decision makers circumvent these issues and find solutions to them.

Here is revealing some of the secrets as always somethings were always meant to be a secret and hence they shall not be part of the list here 🙂

1. All technology decisions are made when people concur amongst themselves instead of a great product or solution influencing the outcome.

2. Implementation problems are not your problems once you ship software.

3. The more open the architecture the more complex it can get.

4. If software testing is so difficult, demanding and challenging, then why is it
that we keep on assigning the least skilled or experienced to perform it?

5. Why do DBAs always sit in a corner or in a nomans land and not accessible to most meetings where their key inputs are needed. Applicable not just to DBAs but to all IT folks who have a say in matters and are not accessible during key organization huddles.

6. The security at the gate checks for what you steal out in pen drives and not the grey matter in your head. IP protection needs more full proofing.

7. Hardware perfectly working software does not work. Typical of people stuck chasing delivery deadlines.

8. SMAC rhymes with SMACK ( negative tone to it ) and hence third platform is better.

9. The dirtier the surrounding better the software , great products were created in garages remember. The formal looking office with great furniture can only produce dot releases and not an earth shattering product.

10. Freemium is a way to get more customers to play with your product but they shall not influence the market sustainability in terms of revenue.

11. IBM pays an undisclosed amount of money to Oracle to use the Java TM on IBM JVMs.

12. POCs always beat many a technical arguments. Always a working piece of software trumps arguments about this way or that way. At Facebook this has been the way forward when stuck in a dead end on this v/s that.

13. Public cloud for where you store your private data ( individual level ) and private cloud where you store public data ( company level / storing data of a large group of people) . This has been the norm cloud security can change this.

14. People do not care about privacy enough instead of saying the opposite. That is the reason why all of us have all our private data on public cloud. Emails , pictures , rants , likes , dislikes and six degrees of separation.

15. Many companies take the same client out for dinner and drinks twice. This happens when they do not streamline and minimize conflicting product lines.

16. Google knows a lot more about people and companies than what glassdoor or others forums or your friends can reveal.

17. Sysadmins and QA teams have more camaraderie than other folks in IT among themselves.

18.  If something is offered free to you as a customer then you are no longer the customer but the product itself.

19. Fixed price project on Agile was not feasible until recently. Things could have changed.

21. CMMI has dispensations and you can bypass any of your stringent processes as long your end customer is fine with it.

22. Guys who work on UI are more outgoing and extroverted than the ones working on Kernel / compiler design.

23. A startup CEO life is short lived once it gets acquired and becomes a VP in the acquired entity and is on his way out to another true calling.

24. If you want to stop a product or project from funding delays ask its ROI from the beginning . This is a sure stop way to projects from being executed.

25.  Business IT disconnect is still the hardest thing to do as there are no good men out there you decently understand both.

26. All corporate extravaganzas are inherently unhealthy .Throw pizzas out if you want to celebrate instead order fresh fruits and herbal tea. May not go well with people who are used to junk food.

27. Do not talk of innovation or design thinking unless the revenue has taken a downturn in companies .

This is not an complete list of secrets but is nevertheless has some points to think about to bring in solutions to the above list that can turn enterprises and organizations into fine well oiled machinery. #turnITaround…

“It is wise not to seek a secret, and honest not to reveal one. – William Penn, Some Fruits of Solitude”

US Library of Congress – Knowledge Management Where are you in your Organization’s journey ?

Leave a reply

1280px-Library_of_Congress_by_Carol_M._Highsmith

 

The US Library of Congress is one of the largest libraries where knowledge of most facets of humanity such as arts, science , astronomy , folklore, traditions , math,architecture etal is stored and preserved over years. This has survived many a century or two as we march in the 21st century and is a laudable effort in knowledge management by any standards. When you want an organization to be built that it wants built to last kind of foundations then it is imperative that the knowledge management surrounding it should be quite solid and future looking.

Knowledge management is an essential component to the Enterprise transformation exercise. The reason being if you are not sure where you currently are then it is not possible to go where you want to go ? It is like having a blueprint of what artifacts you have on your product portfolio and get to know how they all fit in.

Knowledge is like data in a database and management often would how you would manage the data and give meaningful information around it. Knowledge management would be about easy retrieval of information which would mean that you have to a good job of configuration management system around it this is a given and true of all configuration management systems.

Typically in an organization knowledge management would involve storing design documents, code , configurations , tar/war files and all such information that is useful to them and would need to retook at them from time to time.But most often in companies you have people asking around saying do we have an RFP to respond to that client request. Do we have an reference architecture document that would help us is not reinventing the wheel and respond to the client from a similar geography without having to go through specific region specific customization needs. What this means that all of this promotes for greater reuse and reduction of rework and help more better time of an organization’s time and resources.

Do you know what all can be stored in an Organization’s repository ?

1. Industry Standards Information

2. Internal Standards Document

3. Project Closure Documents

4. Governance Log Details

5. Artifacts of all kinds in a company ( code , docs ( SRS , user stories (if you are an agile shop ), architecture specs , business process docs, diagrams,matrices,catalogs)

6. Solution Specific Artifacts

7. Reference Architecture models for the product or service that you are positioning yourself.If you are new to reference architecture then here is a link to a video explaining the same.

8. Have you ever thought of linking this knowledge base to the extent that the information sharing makes sense to your client , partners and vendors ecosystem giving all the IP protection , NDA etal in place.

This is exactly what enterprise continuum in TOGAF paves way for and help an organization create a knowledge ecosystem that will help organization make faster procurement decisions, buy v/s build decisions and simply provide for agility during business transformations.Enterprise Continuum in TOGAF is a concept that has provisions for all of the above and is indicative of how an enterprise should structure its assets if you want to thrive in the knowledge economy. If you know what you have well then you can go ahead and add / subtract the features needed. Most companies at times think it is an overhead along with their day to day run the business model to keep their knowledge base updated.

Most often unit / organization heads have this moment of ground shifting from under their feet when asked “How are we go from this product to the next version of the product?” or “What is the effort involved in getting this product multi currency enabled?. These questions become much easier to answer if you have a strong knowledge management practice. These facts cannot be gathered on their finger tips but with working towards a culture where the knowledge within the company is available to one and all and most important easily structured and retrievable would decide how good it is at business agility and moving ahead.

Image Credit : wiki

Is it time to throw away your Product Baseline ?

1 Reply

throw_baseline_togaf

Baseline as per the wikipedia is an agreed description of the attributes of a product, at a point in time, which serves as a basis for defining change.

Most of us can relate to that statement which means the product or solution has come to a certain maturity in abstraction of its features and now you can call that a baseline. Some companies work a great deal to arrive at a baseline which is what they have worked over months , years to finally arrive at one milestone in their journey and call it the baseline. Now the title is why do some companies decide to throw it away. We shall see how and why this happens ?

Togaf has a concept of going about iterations on how you can go from one state to another in your organization transformation journey. There is a baseline first and target first approach when you go about iterating across its phases for architecture development.

bfirst_togaf

Baseline First : Firstly you go about considering the edifice for building future work is your current baseline and then it becomes the starting point for doing any work henceforth. What this means is that you as an organization has significant has accumulated a lot of collective knowledge and arrived at the baseline which is still relevant and useful in going about the organization churns.Lets say you are a n oil and gas major and all the data models,process workflows,architecture documents ( business,data,application and technology) are at a point where they need further pruning and tailoring to meet the new market realities. And hence any work that you do keeping this as the basis will end up being called as baseline first approach.

tfirst_togaf

Target First Approach : With disruption in every industry at times your baseline becomes completing irrelevant and new forms of transacting , doing business gets precedence. Examples of this would be Banking industry being caught in the wallet war from google,apple etal and further danger from the block chain , bitcoin and newer forms of currency exchange without the middleman. When this is more true for your current state then the baseline or the accumulated knowledge in the organization is found to be not very useful to go ahead with the organization transitions.

In reality this is not very true as there could be pockets sometimes huge areas of the existing knowledge base that can be turned / fine tuned to better meet market or product relevancy in the market. In the case of bitcoin based transactions disrupting banking for example the banking fundamentals such as credit / debit still would remain the same. But again it is upto the organization to see what parts of the baseline is relevant in your journey and then use it to your advantage. This needs good brain storming withing the company weighing the pros and cons and then take it forward.

What’s true in practice

Reminded of a joke that was going on in a company .They estimated that they would need a 100 developers working on the baseline for about 1.5 years to overhaul the product and make it market ready then there was a side remark saying give us 30 developers “throw away your baseline and we’ll rewrite the product afresh in six months.

So the fact of the matter is throw parts of your baseline away where it makes sense keep the ones that aid your transformation. This needs sound existing knowledge of your baseline and also where you want to go. Many organization find this to the biggest challenge “Where are we going and how ?”

Having the clarity of baseline first and target first approach helps …..

Would love to hear from you on what occasions did you have to chuck away your baseline if not great. If so how much of it was throw away and what portions could you keep ?

Image Credit : https://www.flickr.com/photos/strelka/

Does my team understands the BIG Picture ? What can I do about it ?

Leave a reply

Get to hear this question from Senior IT folks , Head of Engineering Units , Product Heads , Vice Presidents , Directors when I talk to them during consulting and training engagements . and is quite a common rant from people in charge of gearing their teams efforts of producing a product or a solution. Help teams with getting answers to these questions ( list is not exhaustive enough but indicative) during my TOGAF workshops coupled with real world experience of having seen how companies ( big and small) come to terms with these issues .

When you are developing software eventually ending up in a product or service , there are a few things you wish everyone in the team was or is made aware of.

bigpicture

Questions that the senior most in the team have or the stakeholders have with respect to their teams.

  1. Does my team know what product or solution they efforts are going into ?
  2. Do they know the customer context in which their application is going to be used ?
  3. Do they have any idea on how the customer is going to be deploying the software ?
  4. Do they have any idea on how the software will be customized at site ?
  5. Do they have any idea of how the project will be measured in terms of business outcomes of the project instead of technical prowess alone ?
  6. Do the teams have the knowledge on what is perceived as waste with regard to the requirements that are thrown at them ?
  7. Do they have the knowledge of how to produce just enough architecture or design ?
  8. Do they understand that abstraction is a key asset for an IT professional as they progress along their career path ?
  9. Do they understand what it means to have a separation of concerns in the architecture across the layers.
  10. Do they understand that business architecture is taking a lot of precedence these days and technology is being leveraged to serve the needs ?
  11. Do they know how to slice and dice the architecture or design to produce a Minimum Viable Product or Potentially Shippable Increment ?
  12. Post slicing and dicing the architecture do they know how to put the pieces back and ensure economies of scale in terms of best effort of people , process and technology.
  13. Do they know that the smartest person is not in the room with regard to their requirements if they are continously being changed .
  14. Do they know that external factors and standard can influence the way they go about their work. How can they be proactive here ?
  15. What is best in terms of delivering software these days that which can avoid the blame game and make everyone accountable ?
  16. Do they have a common repository where all the artifacts can be stored in the organization and this reflects the current state and not just created to impress the internal or external auditors ?
  17. Do they know how an idea can be taken all the way from strategy to execution and what are the layers during this process ?
  18. Are they stuck too much on the solution instead of exploring all possible ways of addressing a solution which can result in better customer satisfaction ?
  19. Do they understand that architectures have a short shelf live and should produce ones with that in mind instead of aiming for built to last solutions ?
  20. Built to last should be an architecture goal instead of being a design goal , designs can change .Does the team know this for a fact ?
  21. Do they understand the logical separation across various architectures and how to go about creating deliverables across sprints or scrum cycles whichever may be your organization’s way of doing things ?
  22. Do they constant understand how to innovate in iterations instead of thinking innovation big bang ?
  23. Do they understand the customer needs enough with a bit of design thinking spiced up along in the way they look at solving things.
  24. Do they understand how to fail fast and fail forward ?
  25. Finally do they understand the BIG PICTURE ? DO YOU HAVE SOMEONE in the team who is helping the team understand the BIG Picture ?
  26. Do they understand the complexities of how software which started at a module level and end up being complex as it progress and loses its extensible nature ?
  27. Do they understand the realities / needs of enterprise grade applications or software and are they design and architecture efforts aligned in that direction ?

The above list is not complete but details the issues that senior folks grapple with who are in charge on producing / delivering software. Would love to hear your thoughts on this.

Picture Courtesy : Flickr Amanda Slater

Eturnti Enterprise Consulting is an Open Group member and has achieved Accreditation on its course on TOGAF® Framework

Leave a reply

eturnti_togaf9

Happy to share that Eturnti Enterprise Consulting is now an Open Group TOGAF® 9 Standard Version 9.1 accredited training partner.

Look forward to spreading the TOGAF® Standard Version 9.1 framework body of knowledge  across people doing business transformations , IT / digital migrations , overhauling their IT infrastructure/landscape and in short wanting to go from point A to point B in their individual organizational journeys….

TOGAF® is a registered trademark of The Open Group in the United States and other countries.