Should You Fire Your Enterprise Architect?

I came across the following blog recently and I felt the same with the Qantas Architects

Now working directly on SOA projects, I'm exposed to many more organizations than I did when I was building technology. As such, I see some common patterns or issues emerging.

The largest and most disturbing issue, and as I mentioned a few times here on this blog, is the fact that there seems to be a huge chasm between the traditional enterprise architecture crowd, and those looking at the value of SOA. Indeed, enterprise architecture, as a notion, has morphed from an approach for the betterment of corporate IT to a management practice, at least for some. Thus, the person that is needed to understand and implement the value of SOA is sometimes not the current enterprise architect in charge.

The core issue is an add-not-change approach to architecture. While adding applications, directories, databases, to an existing architecture is easy and risk adverse, changing architectures around systemic notions such as SOA is hard and does come with some risk. Thus, many are choosing to ignore it. In many instances it's the culture, with some organizations promoting a "you fail you're fired" approach, versus a "let's try new things and seek improvement."

Another issue is that it's easier to stay high level, than do actual work. Drawing diagrams, doing presentations, and writing reports is much easier than actually going out and making real changes with real benefits. Again, from above, that carries with it the notion of risk. Implementing SOA takes a lot of up-front work, as well as many changes. However, in many cases the benefits outweigh the risks by a large margin.

So, should your enterprise architect be shown the door to make room for others looking to promote a better and more agile IT architecture, and are willing to do what it takes to get there? Here are a few questions to ask.

1. Has somebody compared the current architecture with best practices in you industry, looking to spot issues that need correcting, such as the architectures inability to align and keep us with the business?
2. Has somebody done a ROI analysis of the value of SOA, or other approaches for that matter, for the current architecture and reported it to management?
3. Do you have a complete service-, semantic-, and process-level understanding of your enterprise?
4. Do you have a common abstract model for key elements, such as customers, sales, inventory, transactions, etc?
5. Are systems well integrated and communicate in real time where needed?
6. Can you change your architecture to accommodate business changes at the speed required by management and the marketplace?

Basically, if you answered no to any of the above, it's perhaps time to look for some new blood...New Year, new opportunities, new value, new architect.

No offence, but I do think the architects at qantas are sucks. Let me tell you why:

- Site only rely on client side validation
- Site can be attacked by SQL injection
- Some Classes are not threadsafe.
- No coding standard.
- Still using Text Editor in Sep 2006. Only start using Eclipse 3.1 recently
- Most of our business logics reside in JSP and Action.
- As one of the biggest airline in the world. We can't handle more than 500 concurrent requests even they use ad-hoc caching here and there
- Loads of database connection leaks. We have to restart our server constantly.
- Never close input stream.
- Poor exception handling, try and catch exception and then doing nothing.
- Many java file are more than 3000+ lines
- Using Remote EJBs even the web and business tier are in the same box.
- Do not use CMT. What's the point of using EJB?
- Refactoring? No way! I don't know why they don't allow me to refactor the JSPs (moving the logic in a java class, using a template engine, etc). Is there any better place to begin with for refactoring?
- Never understand the value of continous integration.

As a conclusion, I do think the Architects that I work with are very conservative. They are relectant to adopt new technology ( 3-4 years behind the standard). Something that I can do it with Spring, they rather to write it in their own way (yes, they favor inhouse framework) . They write it and never have time to maintain and improve it. Why do we have to reinvent the wheel if someone better than you has done that already?

I know that most of the problem are created by average developers, however, as an Architect, you have the full responsiblity to ensure the quality of code. Not just meeting and drawing diagrams all the time. You can only be a good Architect if you spend at least 40% of your time in coding. My 2c.