Enterprise Architect

In any IT forum, the topic of roles and skill sets of architects is a sure-fire flame bait. There are many roles with the title of ‘architect’ in the IT industry and they can be quite different. I summarise the IT architect jobs into the following categories:

1. glorified software engineers/business analysts – some employers and employment agencies alike beef up the job position to attract more experienced applicants; of course, some employees/applicants do the same to their profile to attract better pay.
2. domain focused solution designers – these architects/designers focus on specific domains of the IT space. The boundaries may vary depending on how you slice and dice the space: infrastructure, security, integration; service fulfilment, network performance, inventory management, etc.
3. enterprise wide architect – responsible for IT governance, IT strategy alignment with the business strategy. It overarches the various domains mentioned in point 2 above.

The Enterprise Architect falls into the 3rd category. Not all organisations have or need to have such a dedicated role – a travel agency with 3 staff may well outsource their IT operations and the role of EA to an external party.  The role of EA is a product of a mature organisation (or mature org wannabees) that understands the importance of IT to their business.  Wikipedia has a pretty detailed description of what EA is. It uses the analogy of city planner (the EA) and domain specific designers and engineers in the building industry. This is a very good analogy and one that I often use. After all, the very term of architect is borrowed from built environment discipline.

It is understandable that many people including IT professionals do not understand the roles of architects, especially EA. The main reason for this lack of understanding is that in many organisations the role of architect is shared with others – e.g. development team lead taking on the responsibility of system architect. When it comes to EA it becomes more illusive because not all companies have one. So it’s no wonder we see in various forums silly questions like should EA be doing coding  (btw, my answer to this question is that EA should not do coding as his/her day job; but it certainly helps for EA to learn new technologies to better understand them – so coding afterhours is great for EAs).

The IT industry is very young and immature comparing to other disciplines liking medicine or built environment. As a result of reaching maturity, it is inevitable for the industry to become more and more specialised. Therefore, the roles and jobs become more and more fine-grained, focused and well-defined. No doubt, with IT becoming more mature, the roles of architect especially EA will become better defined and clearer to more people.

SOA Pitfalls

The Top 10 SOA Pitfalls series is a really interesting read. It reminds me of my first hand experiences of some of those pitfalls.

I was in charge of the solutions for a high profile project in a large Telco environment. In this particular environment, there were myriads of small systems which did not talk to each other. Reason for the proliferation of many small systems is that each department head can approve projects below certain budget. So each time a department/group has some business requirements, the tendency is to have a chewing gum and duct tape solution as long as it stays under the budget limit for the department head. So after years of such practice, users were left with small systems that were small in functionality and an overall complex enterprise systems environment for any IT architects.

The client had come to their senses to change this by introducing a COTS. Part of our project's responsibility was to replace those small systems with the COTS. After initial study, I found that we had to replace 7 small systems and integrate with 17 others. In this environment, a SOA platform is called for. Fortunately the client had corporate license for SeeBeyond (now called JCAPS after Sun bought it). JCAPS had been used in several other high profile projects ($10Ms, 1-3 years implementation time). To my astonishment, each of those project had its own instance of JCAPS running; and these instances were not talking to each other. So it looked like our project was going to introduce another instance of JCAPS silo! This type of use of EAI defeats the purpose of using EAI. After all, the 'E' in EAI stands for 'Enterprise' - it is supposed to be enterprise wide. After some hard fighting, I am glad to say that the project had a happy ending.

Data Logic and Business Logic

The 3-tier or n-tier design has been widely adopted for very good reasons: separation of concerns; divide and conquer...

One doctrine of the 3-tier design is to treat the data tier as data storage and do not implement any business logic inside your database. However, this does not mean that database should not have any logic. On the contrary, any data specific logic should be implemented in the database, not in the business tier.

I recently read an interesting post on using Hibernate Interceptor classes to access the table in the desired schema. The end result of this implementation is to hide the fact that the application is dealing with tables in multiple database schemas so that SQL queries don't have to be littered with 'schemaName.tableName' everywhere. Of course, a simpler solution to this problem is to create a public Synonym in the database.

In my opinion, this 'table routing' logic should be implemented in the database server as it is database design/deployment specific. On the other hand, Hibernate is an ORM framework and logically belongs to the data tier in the 3-tier architecture, so it is not wrong to do it in there, especially if the database server does not support synonyms.

Another real-life example of data logic is in high volume tables - e.g. in Telco billing applications, there are millions of call event records a day; so it is common practice to partition that call event table. In the earlier days, when database servers did not support table partitioning (e.g. SQL Server 2000), DBAs have been manually segmenting tables (e.g. by creating multiple tables: CallEvent_20080201, and CallEvent_20080202, etc.). Obviously the application should not implement the logic of which table to use when executing a query (e.g. get me all call records for today), but let the database handle it - a common practice is to create database view to consolidate/union the manually partitioned tables. An advantage of implementing it in the database is that when you upgrade or migrate to another database server which supports table partitioning (e.g. SQL Server 2005+, Oracle 8+) your code need not change (OK, if you are using ORM, the mapping file may need some modification).

To make a better design decision, the system designer/architect and the data designer/architect must jointly design the system in a collaborative manner.