Inefficient Enterprise Architecture or efficient enterprise infrastructure?

Last week we visited "real-world architects" and of course we discussed the subject on similarities and differences between a real-world architects and an Enterprise Architects. There are some equalities to see in there such as thinking in concepts and principles. The main differentiator is in the in the visualization/conceptualization of the physic world. For centuries we are constructing houses and buildings, so everyone can understand the overall concept of buildings (foundation, walls, doors, electricity, water, etc). So if an architect should draw a building with the public entrance on the 3th level, everyone can comprehend that this will not work. In a case of an enterprise architect outlining a new system, the visualization is not so obvious (or does someone know a good way for visualizing new systems in operation?). Therefore conceptual flaws in an overall architecture are not so clearly visible.

Another interesting aspect was the budget the building architect used relative to the total cost of a project. They estimated that this was 1-3% of the total project cost. In enterprise architecture this part is much larger than 3% (sometimes up to 10-20% ?). In my opinion this can lead to two distinct possible conclusions: 1) Enterprise architecture is very expensive and inefficient; or 2)building enterprise systems is much more efficient than building real-world buildings. I come to think that the second option is the most probable, because in a housing project the engineers have to build/construct everything from the ground up for each new project (foundation, walls, installing electricity and water, etc). In a software project all the infrastructural components can be reused, such as servers, network connections, databases and software components. Therefore these projects can accelerate upon the already installed infrastructure (which is the product of a solid architecture). As a result of the fast development of the system, we as Enterprise Architects use relatively a lot of time in the initial phases of an project. But is this because Enterprise architect are inefficient or the result of the leverage of the "stable, but flexible infrastructure"?

Enterprise Architecture: concentrate on the process!

Together with a colleague of mine we wrote an article for a Belgian/Dutch IT-magazine informatie (www.informatie.nl). In this article we point out how we execute architecture within our company and that we give special attention and focus on the architecture process.

Although referential architectures are key in developing a view on the future, these referentials can be a stumbling block for specific (urgent) business needs. In that case a partial deviation or interruption on the way to the future vision can be allowed at strategic architecture board. This board consist off business and IT management so that they can decide from their responsibility and general consensus.
In short the future vision embedded in referential architectures is important, but the architecture process is also (or even more?) important. This is written down in the article (in Dutch only).

If you agree or disagree with this statement or have any other comments, please let me know!

Changing borders Business will become IT

In many companies the implementation of Business Rules Engines and product engines are executed or planned to be in the near future. Often the biggest reason for implementing these type of solutions is to parameterise decisions or product specifications that formerly were hard coded in software. When implementing the business is back in the driver seat again, and we can quickly implement changes without the IT-department.

All this is true I think, but I see this as a next maturity stage in software development and maintenance. When the business sees the type op parameterisation required, they will see that this is very strict and formalized. In a way it is another way of programming the system by function designers.

It is my opinion that after a while the “real” business will decide that this type of work should be done in the IT-department and that all the personnel trained in configuring rule engines and product engines will be called IT (again). So the borders of the business will be moved toward the business core competence.

Please react or give your comments.

Poor man's knowledge management

Finally my team pulled it off! We are allowed to use Google Desktop Search at our company. Yes it took a lot of convincing people (“why do you want to search in your own documents, we will implement enterprise search in a couple of months…. “). Well we got it and within a week it increased my working speed. In my opinion this is a poor man's knowledge management tool to the full effect. But a very pragmatic one!

PS 1 Though a shame that GDS doesn’t index mail attachments… Copernic does and has a better preview option so I use Copernic at home.
PS 2 I Love Google :-)

Flexibility the Holy Grail

One of the most heard benefits of SOA and/or BPM is the increase of flexibility. Well I doubt if that is the case. Of course we will build more flexible systems than a few years ago, but the bottom line is that business processes do not change so often. For example in the case that an insurance claim above 20K Euro has to go approved by the team manager, this amount can be changed very quickly at runtime in the Business Rule Engine or BPM engine. So far nothing new, we have done this also in “legacy systems”.

In my opinion business processes doesn’t change that often, therefore the flexibility claim is aimed to high.

Run IT as a business

Why aren’t we running IT as a business nowadays? Still far too many projects are abandoned before they ever are released, or released with specs that don’t meet client expectations or with far too many defects.

In our company we cope with a lot of different technologies. It is difficult to see if one team is more effective that another team, of course (the good old) function point analyses can be used. But are we measuring the right things? How many time did we spent at the design, realisation and testing of a solution. How many errors were there made in the final solution and how long did it take to resolve them.

Of course there are some fragmented tooling that will help to get some insight, but real holistic management figures are rarely shown. So it comes down to people. Leaders and managers (two different things) that are running the IT business for a company to leverage the expectations.

One thing is for sure; our business executives will request this more and more from the IT-counterparts.

Without tooling "running IT-department as a business"is a farce.

You al heard the rumours of running our IT-department as a common business line. Well that is a nice one-liner that chews away very easy at board room level. "Yes that is the solution for our problems with IT, we weren’t running it as a business. Those guys were pretending they were extraordinary, but the last few years we have seen the other side. Now it is over, we are going to run this department as a usual business."

Personally I totally agree with most of this vision. No there is no real magic in IT when you strip down every technical obscuring problems. But to really run/manage IT as a common business line they need the proper IT-system to support their task. I have seen many IT-managers complaining about the use of Excel in the business-lines. That’s totally true, but the sad part of is that the IT-department is probably the champion! Excel sheets of project, use of budget, managementreports over time-sheets (although there is a sophisticated time & resource management system in place). What I didn’t see so far is an integrated IT-system to support the whole IT-department (a kind of ERP system for this department).

With an integrated system I mean, a system that can track all the projects that are in progress, which I coupled to an architecture landscaping pointing out which part of the architecture is touched. Answering simple questions as what are the top-5 critical business components (services, DLL’s.). How many percentage of my programs are written in Cobol. When I am taking out this part of the system, which business processes will fall over. As I said before to my knowledge I haven’t seen such an system (and yes Tivoli, Telelogic, Popkin, Niku, etc, are only addressing a fragmented part of it).

My statement we can run IT-as a business very cleverly, if we have an integrated IT-system. Any comments/ideas/thoughts?