Giving one example with my experience, I was a solution architect working together with another guy for implementing BPM (business process management) of so call money movement (with a financial company, there are 4 types of moving your money around: ACH, check, wire and journal). We came out a nice logical architecture model consisting of IBM BPM, IIB, MQ, Oracle databases and mainframe (Non-stop) components. Going along with this model, we have to create about 8 services providing more than 20 operations to realize the architecture. We presented the architecture model and initial service specifications to the management & team, and got everyone thumb up. However, I was suspicious about the complexity of the whole architecture. I let my thought flow around, and debate this architecture with myself after working hours with a fresh mind. After spending time back & forth, I found there is absolutely no need of one component in this architecture. I removed it from the model, and surprisingly I was able to cut the services to only 4 services and 8 operations after removing this component. Voila, how much I saved for the company, I estimate it would be at hundred thousand range (not only the reduction of development effort, but also support and maintenance, etc).
Currently I am facing a similar situation where a thoughtful architect could make a better (or wise) decision. The situation is a typical integration use case where an incoming message to IBM IIB (my client names it as EDB - Enterprise Data Bus), and then to data service layer (EDH - Enterprise Data Hub). The use case is to look up or match a customer by a few attributes such as an unknown ID (could be a customer ID already in the system, but not necessary), first name, last name, DOB, gender and address. Initially, a solution was proposed by a guy that IBM ODM (Operation Decision Management, aka rule engine) will host the matching logic. In fact, the matching logic is like: (1) Use the unknown ID as the search criteria to find customer(s); (2) If one customer match is found, stop here. Otherwise, add other attributes such as first & last names into the search criteria and continue the lookup. Again, if one customer match found, stop here. Otherwise, add other attributes, and repeat the similar step above. To me, the matching logic is very similar to what happens at database side. For example, taking rational database as an analogy, the matching logic can be sql query with SELECT, JOIN and WHERE clauses. Furthermore, it is very clear that database query could be very efficient (as long as you don't use database cursor) no matter it is a rational type database or no-sql database. On the other hand, if the matching logic is implemented in ODM, loop into each record (where more than one match is found) would take place. We all know that the iteration of each record could be inefficient. Therefore, I was the person starting questioning about this solution. I raised the question a few times during a couple of discussions like " Do we know if ODM can do this matching logic more efficient, comparing to database query?". Another question I asked people is: "is this matching logic suitable for ODM?" considering there two major criteria of using ODM: one is that the business rule would be changed often; the second is if the rule implemented in ODM can be modified by business people. Another point is that adding ODM into the whole solution creates more complexity in terms of infrastructure as well (for example, high availability, failover, etc). I am not against using ODM, but I want to use it in a right way with right use cases.
What I am trying to say here is that a thoughtful architect is a valuable asset to any IT organization. To be a thoughtful architect, she/he must be equipped with some characteristics such as:
- Never take any proposals/solutions as granted, always be ready to provide arguments about pros and cons of the solution. Even someone tells you that his solution follows existing pattern, you still have to keep debating and questioning at the solution in order to find potential areas to improve (of course, existing pattern provides high level of assurance).
- A thoughtful architect should hold holistic view of all aspects with software/application/system, such as development effort, infrastructure layout, operationability and maintainability. Furthermore, take both functional and non-functional requirements into account.
- A thoughtful architect must have implementation experience with engineering mindset. He must be an expert in his technical domain, with broad experience & knowledge of other technical domains. A high level only talker is not enough to be a thoughtful architect.
- Try to simplify any solutions. If a solution looks complex, be more alert and suspicious. (again, one of my principals is that everything has solutions, but the best solution is also the simple(st) one. My whole goal is to find this better yet simpler solution!)
