Grey zone August 20, 2009Posted by Terry.Cho in Software Engineering.
Tags: Consulting, Context, Grey zone, Problem solving
add a comment
During reading some article in a blog. I found very interesting term “Grey zone”
I like this term and decide to use.
During IT project, “Grey zone” is occurred usually. It is “Everybody know that they have a problem. But it is not clear and ambiguous. Nobody try to solve the problem. Just ignore and leave them.” That is “Grey zone”. It commonly be a big problem at end of project. This problem is caused by ambiguous role definition and losing a context.
Customer wants to solve the problem but don’t know about that exactly. – “What is the problem? and Who has a responsibilities about the problem?”. If customer asks the problem to project team member. They don’t want to mention it or don’t provide exact information. They are afraid that can be a new task or burden for them. So they try to hide them.
To solve this “Grey zone” problem, consultant is very useful.
- Consultant doesn’t have any responsibilities to solve the problem.
- Politically Consultant is neutral.
- Consultant has a fame or reputation from their title or their company. So their suggestion has more value than other stake-holder’s suggestion.
To solve the “Grey Zone”
- Catch the problem and cause
- Provide a few solutions
- Let customer select the solution.
As a result, solving the problem is customer’s responsibility. In my experience all of customer know that they have a problem but don’t know exactly what they have to do. The problem is hide behinds of many wall that made by project team and politicians. Role of consultant is that get rid of the wall and show naked problem to customer.
Absolutely during solving the problem many stakeholders try to defense them. We need some skills to overcome this.
My recommendation is “Data”,”Documentation”,”Presentation”.
Gathering data , make a document and present it in front of stakeholders and customer. Data is objective. Brilliant presentation helps you to convince the problem. Finally you can give a sword that can cut the problem to customer.
Do you agree on this?
I have worked as a fire-worker in many IT project. I usually did like this and it have worked very well. So i can get a reputation from customer and raise up my consulting value.
Leverage communication with DDD (Domain Driven Design) August 19, 2009Posted by Terry.Cho in Software Engineering.
Tags: Collaboration, Communication, DDD, Domain Driven Design, Project Management, Team
add a comment
I am a consultant so now days I am looking at DDD (Domain Driven Design).
One of important point in architecture analysis and design is “How to extract requirements from customer? And How to visualize the requirement by using model?” Model itself is not an objective but a tool or method. It acts as common language between stake holders. And it helps us to communicate more effetely.
Another problem in project is communication. Sometimes stakeholders (Developer, Customer, Different biz team, Analysist, Architecture) in the project misunderstand same concept to different meaning. It makes many problem and communication cost.
Common problem of these is that “Project members don’t understand Context”. It is communication problem. If all members in the project can share the context and understand same concept as same meaning. We can prevent problem from mis-communication.
DDD is started from this concept. Basically it describes communication way between domain(business part) and programmer (IT part). It also explains software design pattern etc. But I have a interest in communication and how to share context etc.
Let’s summarize concept with figure.
First step. Construct main model.
First step is ‘analysis target business’. Describe business scenario and flow by using some diagram. You can use any diagram that you want like UML, BPM or Use case. But it has to be effective and easy to understand for communicating between biz part and it part.
All of biz and it people have to use same language. We call it as “Ubiquitous language” in DDD. It is business(or domain) term not a technical term. For example “JMS Queue”, “XML Message” – this is technical term. “Account”, ”Transfer” – this is business term.
Use biz term for communication!!
Another important thing is “make glossary”. Term is always important and it always be a cause of miscommunication. Even if we are using same biz term. It sometimes can be different depends on organization or role. So we have to make “glossary” It is also useful when a new member join the project. We don’t have to explain term to him but just pass glossary. I suggest use glossary in wiki pages. It is always live and easy to search. (Don’t use Excel or word document for glossary. It is a tomb of document)
After making main model and glossary we can start communicate with same language and share context.
Second step. Separate main model.
Second step, cut the main model to small pieces with details.
Project members have a interest in just what they have to do. Main model let us to share and understand context. Sub model let us know what individual people should do.
In DDD, it uses “Boundary Context” to cut the main model. The boundary can be organization or business function or unit etc. When cutting the main model if it has a dependency to other sub model, you should include the dependency in your sub model. It makes members to recognize dependency to other biz (or sub model) in your sub model.
When we cut the model, providing traceability between models is very important. Every sub model has a relationship to main model and other sub model with boundary, dependency etc. If we do not state the relationships, somebody can lose a context from sub model.
There are many ways to provide traceability like structured numbering (1. 1.1 1.1.1 etc). But numbering is not effective. Even if it can provide traceability , ratability is low . Diagram is more effective. DDD introduces “Context Map”. It looks like mind map. It describes model and relationships between the models.
Third step. Make common model from sub models.
After cutting main model to sub model. We can understand “What is whole system to do?” (by main model) and “What is my role and boundary in the system ?” (by sub model). “Whom I have to talk with and co-work with ?” (context map)
As I mentioned between sub model , there are relationships. It tells us it can have common module.
In third step, extract common module between sub models. DDD named this common module as “Shared Kernel”. DDD guides ownership of the “shared kernel” is teams that related the shared kernel. But I think it is very hard. People always push their role to others. My suggestion is give a role of “shared kernel” to one team specifically. And if there is some concerns or issues between the teams, Architecture Team or Project Management Office intercede it.
Keep sharing Context
Even if we made model, sub model and context map. All of them are always changing. To catch up the changed context we have to share the context continuously. It is Continuous Integration (CI). CI term is used for automated build and test automation. But in this article CI is like a review meeting. Periodically review model with stakeholders and share the context. It let us to keep same contexts.
DDD describes about communication model and traditional software design patterns (like Gof’s design patterns) But the design patterns are already introduced by many other documents and books. I want to emphasize communication and modeling ways in DDD. Main model, Sub Model with boundary context, Context map and CI is very nice way to communication and context sharing