Principle of Articulate Domain and Founder of Domain-Driven Design United States. Adaptive systems designer avoiding accidental legacy creation. Fan of the recent Learning Domain-Driven Design by Vlad Khononov. After leaving the US Air Force in 1997 as a Radio and Television News Reporter, held roles as a Developer, Business Analyst, Dev Manager, Product Owner and more.
Industries served are print, direct sales, banking, government, and insurance. Experience in startup and enterprise environments.
John lives in Salem, Oregon, with his wife Sandy and two kittens, Martini and Matisse. They head to the Oregon Coast when time permits.
When terminology between the business and IT gets out of control it may seem like you need the skills of an FBI Negotiator and/or therapist to get to the facts and make quality adjustments that serve the needs of all involved. So what if you had those skills? What if you could peacefully and systematically guide the business and technology onto the same page using communication tactics from respected professions that rely on high quality communication to get the answers they need.
In this talk, we do just that. We work through how to relate with people using easy to learn, highly effective methods of driving a conversation to a resolution. Then we apply those resolutions to a process that tracks the decisions made to rectify terminology issues.
This talk is for you if:
John Connolly has grappled with this often and has adopted techniques from investigators and therapists alike. In addition, he created a process he uses to facilitate the exposure of these conflicted terms. This process gathers the facts around their usage, agreements on the future state and ways to make sure the business knows what it takes to repair these often-wasteful discrepancies. He will present, demonstrate and discuss this process and these techniques in a way you can immediately implement in your role - even if you do not know Domain-Driven Design (DDD) at all. In fact, becoming effective at terminology repair will help you understand a key element of DDD more experientially - i.e., the Ubiquitous Language.
If you have these terminology issues and want to have a way to solve them, come check it out.