Working In Architecture Spaces

The way we approach to work is important in any discipline in general and in software architecture world in particular.  A SW architecture need to work in following works spaces

ü  

       Preparation Space

Problem space

Solution space

 Opportunity space

The following figure explains each of the above spaces 

Architecture Spaces 

AS& SMART – Architecturally significantly specific, measurable, attainable, reusable, reusable and testable requirements.  

Mafia offer/suggestion – An offer/suggestion which is so good that it is easily accepted by the respective stake holders.   

We seldom spend any time in preparation space explicitly. We need to spend time in preparation space explicitly so that we can be ready for the assignment in hand. Professionals in other fields, e.g. sports,  spend considerable time in preparation space and their ultimate success depends on how well they spend their time in this particular spaces.  Out of the above four spaces, we are going to spend maximum time in solution space. However, preparation, problem and opportunity space are point of leverages. By spending some additional quality time in these spaces, we can considerable reduce time spend in solution space. We add more than proportional value to stakeholders.

We should not work sequentially in these spaces. We should able to move from one space to another space depending upon the context and practical situation. While working in one space, we should be totally isolated from other spaces. For example while working in problem space, we should not think about the solution. While working in any space, we should always keep the current context in mind.  

It is also important that some time we work in opportunity space. In this space, we should ask some probing questions as mentioned in the above figure. This can help to innovate in process, product and services and next practices.  Mark McGregor is right when he says that we  do the catch job by implementing best practices and gain real sustainable competitive advantage  identifying and implementing next practices on continuous basis . In future only those software professionals will survive who not only follow best practices but can think of next practices, next generation of products etc. on continuous basis. Hence working on opportunity domain and asking probing question will be critical  success factor for future software architecture professionals. 

T Profile – Specialist Generalist

From quite some time, professionals have been classified into two categories – Specialist and generalist. Generalists are the peoples who know something about everything, but have little deep knowledge and skill in area . While specialist are the people who have deep competencies in one area but have virtually no knowledge or skills in any other areas. Even in software world professionals are classified into two categories – people and technology. Professional with people skills are suppose to have some magical skill in dealing and communicating with other peoples and need not have any technical skills. While professionals with technology skills are obviously suppose to have deep technology skills but very little skills in dealing with people and communication. The really important question is, professionals with which type of profile will be required in current and future world. Once thing is certain – in future, every professional will be required, not only to work efficiently, but also continuously innovate. Innovation means doing something new and different which deliver enhanced value for money to all stakeholders. In the world of software, professional, who will have maximum potential to innovate, are likely have T profile. People with T profile, on one hand will have breadth of knowledge in software and other related disciplines; on the other hand they will also have deep competencies in few areas. Innovation required a wider horizon with deep insight. Only T profile can meet such requirements. Every software professional should have a knowledge and skill portfolio in line with T profile. He should make an explicit attempt to acquire his new knowledge and skills as per his knowledge portfolio. Google allow its employee to devote 20% of their time on projects/ideas which are purely decided by the employees themselves. A software professional should also devote some % of his work on his knowledge portfolio. He should periodically review his knowledge portfolio in order to align it to ever changing field of software development.

Writing requirements in the form of elementary facts

It is an established fact that specifying right requirements is the fundamental to any form of successful software development effort. The critical question is what the best way to right requirement document? In a good software requirements document, "what" should be clearly separated from "how"? Further, a good requirement document should have right mix of generalization (For reuse) and specialization (for better understanding). In a good requirement document, the core business capabilities should be clearly separated from how these capabilities are implemented. Core capabilities are business functions of a particular domain which do not change for a very long time. For example an auto insurance company should have core business capabilities of "creating policies, issuing policy, claim management, payment etc." Here is an example of  requirements specification  for payment against claim –

"System should has the capability to make on line payment against a claim"

In the above sentence core capability - payment (what) and means of payment – on line payment, has been mixed. Mixing of core capability and means to implement it give a wrong understanding of requirements and may lead to software architecture which may not be agile. A better way to write requirements is to write requirements in the form of elementary facts. Elementary fact is a fact which has been simplified to such an extent that it can no longer further simplified without loss of meaning. An elementary fact it is always expressed in a single sentence and sentence focus is on one and only one thing. Here is an example of requirements written in the form of elementary facts -

System should have capability of payments - What, G

Payment is made between two parties – What, G

System should have capability to make payment against claim – What, S

Payment against payment is made by auto insurance company to auto repair shop, S

Payment can be made by various means - How, G

Some means of payments are – How, G

On line payment S

Payment through cheque S

Payment through demand draft S

Settlement 

Settlement is a single payment against a collection of claims 

G stands for Gernalization    and S stand for Specialization

The requirements written in above manner are more likely to be understood correctly by architects/developers. The above method of writing requirements is also likely to create more generic and reusable requirements. Each elementary fact can be easily classified into what or how and generalization and specialization. An architecture developed based upon such requirement is likely to be more agile and have right mix of generalization and specialization.