Digital Solution Anti-Patterns I: Expose the internal organizational structure to your customers
Introduction to the new series
With this blog post I want to start a new series about business decisions and technical decisions (i.e., Digital Solution Architecture Decisions), which are a) obviously bad and b) heavily impact customers (i.e., I have encountered them). I do not do this to particularily roast the companies and organization described in this series. Instead they serve as a real-world example and I want to distill some rules out of these examples describing what software/solution/digital/domain/digital solution architects should and should not do.
The structure of these anti-patterns is not 100% pattern like. Indeed some people would argue that the rule of three examples is broken because I only demonstrate each anti-pattern by one personal example. However, I think we all (myself included) learn from these examples and avoid these problems!
For every pattern I will give you a short description of my encounter, a list of problems, and a checklist for you what you need to check in order to avoid the problems. If you like such patterns please do not forget to subscribe to my blog notifications at the bottom of this page. So let's get started!
Introduce your customer to the most number of your departments and employees in order to check whether your services are so good that he/she is crazy enough to still use them. In case he/she is even crazier, you have identified the best next employee to hire, who coincidentially already has a deeper understanding of your organization than your managers!
This example took place when I was employed at the University of Hanover in the software engineering group and was doing my PhD. This regularly involved visiting conferences (a rather nice side to working in research). The university had (probably still has) a business account with the german railway (Deutsche Bahn) and I was VIP customer (bahn.comfort) as well. I cannot reproduce the correct year but it has to be between 2004-2009.
- I ordered a ticket with the business account and my VIP customer number.
- I could not use the ticket because I took another train.
- I could not refund the ticket at the station when I arrived back from my trip.
- I could not refund the ticket online.
- I contacted the business customer service, who could not refund the ticket because it was a VIP customer ticket.
- I contacted the VIP customer support, who could not refund the ticket because it was a business ticket.
- Cycled three month between both support hotlines until I finally managed to get connected to a competent and friendly woman who a) acknowledged for the first time that there was indeed an organizational problem and b) who solved this in 2 business days to get my ticket refunded.
- Under some (not that uncommon) circumstances a standard business process could neither be conducted online nor offline nor on the hotline.
- While achieving the customer's goal, the internal company structure was exposed to the customer.
- No solution was offered to the customer due to organizational boundaries and silo thinking.
- In a business object oriented organization structure, the assignment of some possible business objects to the departments was not clear.
- Does the customer ever unnecessarily see that he/she is interacting with different departments of your organization?
- For all possible attribute combinations of a given domain object, is the responsibility in the organization clear?
- For all possible attribute combinations of a given domain object, is the master system clear?
- If the customer interacts with my organization, is it clear to him/her in what way to contact the organization?
- If the customer interacts with my organization, can he/she reach his/her goal via his/her preferred channels (online, offline, phone, email, ...)?
- Can all of his/her inquiries be handled successfully at the point of contact?
<<< Previous Article
What does the best API for creating JSON/XML message payloads look like?
Next Article >>>
Why Germany failed to combat COVID-19: inefficient bureaucracy and no technology
Subscribe to get notified for new articles!
There are more articles to come. If you want to stay informed, please leave your email address to get notified!
Dr.-Ing. Daniel Lübke is a Digital Solution Architect, who enjoys realizing high-quality business processes in software. He has over 10 years experience in architecture of distributed systems (from SOA to Microservices, BPM and workflows). Daniel likes to find better than "state of the art" solutions by combining methods from Software Engineering and BPM, in addition to researching promising, uncommon solutions. He is book author, editor, and speaker at conferences, and has published many articles in different magazines and journals.