Monthly Archives: September 2013

Centralize Interoperability and Decentralize Implementation


Most often in Organizations we have a crucial process that most often is referred to as governance or project monitoring or simply operations at times. What this means is to look for facts and figures and data in the system that are not aligned to the organization vision / mission long and short term and set things right. Do what is required to set things right including pulling one’s hair out / fire fighting or simply status meetings and reviews. In the midst of all this various governance / steering committees are created which acts as custodians or guardians of organization know how or the gatekeepers keeping a vigil on how things are done.

Turn your developers into Rock Stars and Managers Into Rock Star Promoters is an other way of saying give developers the freedom to do things that they do best and let architects/managers do what they can see and the developers cannot see. This means things like getting an approval for a module specific change deep down in one’s own code ownership should not involve going around people to get approval. Decentralize these kinds of things in the organization with adequate code review / test unit process and ensure overall sanity of the changes. We do not need much effort on this front to set things like this rolling. Whereas lets say there is a change that crossed two product solutions / interface and involves a messaging layer change or impacts one or more teams solutions. In this case Centralize this Interoperability aspect and ensure the stakeholders from both sides are involved including people with the right skills required to take the decision are present for deciding on these changes. This way architects/managers or senior members of staff who are capable of taking a decision on this should be involved in such decision committees. This ensures there is less red tape in the system and more control at the same time where required and adds value.

Saves Time / Money and Precious Organizational collective time : At times every organization gets caught up in first setting up a process and then breaking the law themselves when it becomes too rigid to follow. Review your process every now and then and follow this principle to eliminate waste occurring due to collective involvement of people not really adding value to the process. Also this would promote organizational flexibility and agility where people go ahead and make changes confidently , check in the code and prevent show stoppers in the pipeline. Remove the barbed wire/fences here would ensure people feel encouraged to owning things up and cleaning up their act. Instead if we route all things important via a central decision making body then it is invitation for disaster. Developers who shy away from meetings will not be ready to even raise these issues fearing a meeting with all and sundry and having to explain the rational which may not make sense to others. Yes empower them and also ensure that the are enough code review processes/checklist for various modules/process which people are following. Also the source control repository should have details on who checked in code/artifacts and back trace it with a  ticket tracker. Once this is there in place then let loose the need to monitor every thing that goes around. Instead use this time to review things that span product interface boundaries , cross solutions where there is a real need for tight control and strict governance.

Release the barbed wire around your teams and let people contribute/own things and co create greater good for the organization. At times it is good not to have any formal authority and works well in smaller teams where agile practices are practiced and but this concept can be extended for an extended enterprise which would be agile at scale scenarios.

Do you scope NFRs in the beginning or end of your product/solution ?


There are multiple questions that come up when we think about the NFRs in our product or solution. The normal practice is these days accept they will show their head in the product eventually but feign ignorance at the beginning of the product / solution as you are busy doing other things , like getting the product up and running. Most often you know very little about these in full detail at the start of the project or work. You may know that there are some implicit NFRs like the user should not experience unacceptable delays or his/her UI experience should be good. These are like eating food at a particular restaurant and having to comment on it. Many people have many views.What would be the common denominator here ?

When you scope the design of your product / solution it is quite accepted that these creatures are usually hard to deal with are there but you know they will not pose a danger immediately and you can be friends with them at least. So what is the accepted way to design NFRs or look at them at the beginning of the start of work.

While you prepare your enterprise or business requirements take a note of the fact of what the product is all about. You cannot get all of them right here , accept it. As the product is itself evolving there is very little knowledge of the system in the beginning. You have a product in mind but as you see the wire frames, screens, prototypes and the product itself in some form on the road you will be able to get to know where to head with your NFRs. Most often this is true that you do not even know the exact number of users who are going to use your system directly or indirectly. So the sane way forward would be to crystallize your enterprise/strategic and business requirements and use your judgement to see where these will impact your solution/product and allow scope for these in some little way at the start and keep evolving from there on.

Things to do to scope your NFRs in the beginning of the project or work :

1. Understand  your product / context / solution in good details and who your end audience is going to be. What mediums/channels will they be using your product / solution. Leave no stone un-turned here such as what channels , devices they will be using including handhelds/phones/laptops/smart phones and what exact versions will be used here. Do check the list of user bases in these categories and arrive at what will be done to scope the needs of these people who will be using your system.

2. Have a NFR checklist / template and be aware to use them on how they might impact your solution. These are either organization repository artifacts or industry specific ones available / published as a part of known things to be taken care of. This will help you with at least glancing through some of them even though they do not look obvious at the start of the project. Here is a look at high level list from the ISO 9126 wiki list read more.

3.  These templates are extensive questionnaires dealing with all the types of scenarios that the user can land. Go through them with the performance validation folks or sit through people who have done this and arrive at the complete list specific for your context. Have a list that covers your requirement.

4. Conduct a series of short workshops either one on one or select participants who have knowledge of the business or context and then work towards preparing the list of NFRs the system should be ready for. This will reveal a lot about the system , talk to the end users , people who have been playing around with the system and test people.

5. Throw open your solution to folks internally in the system if there is already some form of solution that you are planning to improve upon. If it is a totally new from the scratch solution there may not be any organization knowledge on how to do things here. Do let the people who have UI experience , the end users give them your inputs or experience here. This is generally the case of a patient who knows more about a particular disease than the doctor on the same subject. Take all these and add your own judgement with due diligence here.

6. Get experts in each area be it security, performance, clustering, load balancing, UI to give them their gyan on how they approach these issues. Get these vetted against what you have scoped already. Have a sign off from all those who can cross check and use this baseline as your initial list.

Scope everything that can go wrong with the system and plan for them. 

As with systems more clarity will emerge as we go around iterations of the product and things get more refined and clear. Also when you design your system always check for the alternate flows on what could go wrong with your system in all the flows. If you are using a messaging system or third party provider for SMS messaging then check what if one message gets lost along the way. This will help plan for some really crucial quality attributes here. As your system evolves your functionality although was the same from day one you will find the same being presented in multiple ways to the end user.

These steps as a starter will help get you out of the alligator pond where your only option would be be friends with these creatures or risk being eaten up.