Enterprise computing.

That is quite controversial overview and it is just my 2 cents that may help to create that guidance or outline for <THE COMPANY> developers you want to see in place.

There are my thoughts about enterprise computing and some trends in IT industry we may see and which may affect <THE COMPANY>.

I will try to be brief as the topic is extremely broad therefore some sentences may sound unreasonable/unexplained/etc. I offer to take this document as a start point and create some company wide document, which will state <THE COMPANY> point of view and outline development policies and architecture.

Today IT industry has achieved maturity and that requires us to reevaluate and review our mindset regarding Software development. When we look around then we may realize that business developers do not have to be involved in system level development anymore.

By saying “system layer” I mean:

• Databases;

• Text editors;

• Various libraries to deal with direct hard drive access, email, ftp, database connections, sockets programming etc.

At the same time we may realize that business developers are still involved in such kind of activities. It may be beneficial, but in 95% cases it causes unnecessary duplication of efforts and leads to:

• Longer time to implement a solution;

• Poor design and high maintenance cost;

That is not because of stupid developers, but because of problem’s size and complexity that is NOT visible initially. We are often mistaken by apparent and simple solution that will turn to be simple just initially and lead us to problems in a long run.

We should be humble and admit that Software is “engineering” discipline, not scientific one in the same sense as car industry is not about science mostly. We should admit that in most cases typical (boxed) solution works just fine. (How many of us order hand/custom made furniture? car? cloth? food?)

Software is not a black magic anymore and more and more people understand that despite they may have wrong assumptions and ideas about realities of software development.

Processes inside of computer, TV, VCR, or car are enormously complex, but we are able to use those things without significant difficulties. I claim that IT industry is coming to the same point as car/TV industry and this is driven by customer demand. We do not have to change our habit when we buy new Chrysler as a replacement for old Chevy, we are expecting to see the same acceleration and brake pedals, and even more we are expecting to find brake pedal on left side and acceleration one on the right.

That was a lengthy process of defining requirements (expectations) to certain things and it is still underway.

As customers we have some reasonable expectations and they must be satisfied. We would expect that TV has volume control and merely believe some vendor that will try to sell a bit cheaper TV without volume control, but promising that volume level was chosen by experts to satisfy our needs and may be adjusted on demand by specially trained professionals, which are available 24X7 via customer care help line. Sounds silly? But it is sad reality of software industry. Another extreme example might be attempt to sell a “construction set” instead of TV.

When we want to build enterprise IT infrastructure then we are interested in “construction sets” as well as in “boxed” solutions if they fulfill our requirements. What kind of construction sets we need? is another question and it is $1000000000 question.

If we need a custom XXX, then there are hundreds of vendors will be ready to sell construction sets to build XXX. Then we may realize that some of them sell just unassembled XXX that means we can create one and only one variant of XXX. In other cases they will try to sell a very basic construction blocks, which may be used to build anything and our XXX too of course (like selling bunch of capacitors, triodes along with several schemas to the guy who wants to build a PC).

What I am talking about? Well, I think it is time for business(es?) (developers?) to cool down and take control of market, rather than vendors. Vendors at some portion drive every market, but they try to satisfy customer’s demand.

If I need toothpaste I can choose from many and I will not have problems if I will change brand tomorrow (My teeth will not be destroyed by incompatible toothpaste).

I would claim that there are almost no technical limitations today and our problems mostly come from not recognizing that.

It does not make sense to try to invent ONE OS, ONE language, ONE something. It will not work. (As that attempt to use Esperanto as universal human language.)

Solution: balance. It is only thing that works despite apparent difficulties in achieving of the balance.

Outcome: choose some mainstream technology and do not jump between them.

What to chose? Well, there are two major choices – MS or Unix based opposition.

I would recommend Unix based camp. What is wrong with MS?

There is conceptual problem with MS approach: ONE solution that fits everybody.

Such thing cannot work in a long run. Such approach may have short-term advantages but it is flawed in its basis.

From historical perspective: “dictator” may give may give some help his vassals for a moment, but vassals never win in a long run.

Cornerstone of Unix ideology: Combine bunch of utilities to work together to get done job for YOU. That is much more difficult than pick up a solution that seems to be suitable for me now.

But it is easy to provide some prepackaged solutions for particular problems with this basis and do not have disadvantages of that approach: this solution will do everything for you because you should not have other needs.

“You should not have other needs” approach works well in 90% complicated cases and 100% in simpler cases (Create/Read/Update/Delete –only things which can be done to a row in database table).

I think enterprises are sort of clients, which need integration and flexibility that may not be achieved with boxed solutions.

Do I think Java is 100% suitable for businesses? Probably not in its current stage. Originally Java( as well as J2EE) was designed to be an integration layer and in the sense it is PERFECT solution that significantly simplifies business development. It looks like greedy marketers pushed it to inappropriate place. Java and J2EE are about integration in their basis: JNI (Java Native Interface) to work with C (it is not a surprise as it is a language of Unix OS and it is easy portable between platforms),

JCA (Java Connector Architecture), RMI-IIOP – to be able to integrate with anything else (and be integrated in) with using CORBA as glue.

What is my point? Businesses should be focused on INTEGRATION, rather than on unification (use THE language/platform/etc.) Who cares what language is used to create ORACLE RDBMS? We know how to maintain and configure it and it is enough for us. Because ORACLE has JDBC/ODBC/OCI interfaces we do not care what is inside.

What is the problem? Quality of in-house development and volume of the development.

Volume: as we cannot integrate things well we are trying to build simple/limited/custom/blah-blah-blah in-house software rather than leverage existing things. Another huge problem is knowledge sharing even in open environment.

Quality: tools cannot solve the problem. This problem can be solved with:

• Minimum amount of in-house development (integration)

• Education, thinking, education, thinking, education, etc.

Quality and Volume:

• avoid duplication on all levels, code, functionality etc., etc.

Another important issue is “Lack of IT knowledge among business people”. By no means I suggest everybody go and take programmers lessons. No! I am talking about adjusting own habit to abilities of your partner (developers should recognize business people as partners too!!!!!!!). It is win-win balance that we did not achieve yet.

For instance: we are slow down our cars before sharp turn and aware of limits of fuel in tank. Are we all some sort of car mechanics? No, but that awareness of car’s abilities helps us to get most of them and allows car to expose its best.

As you noticed I use real world examples here and there because I do not differentiate “virtual” program objects from real ones. They follow the same common laws as objects in real world and that is just make sense to treat them and real ones.

My prognoses:

• Most vendors (including SUN) will consolidate around CORBA (There is an interesting shift in recent EJB specification and guidances? NOT presentations!)

• MS will promote remoting as a way to get done something useful;

• Both camps will say: we have to deal with that slow and inefficient technology because of guys from another camp;

My suggestions:

• Join that camp of MS competitors;

• Use Java for majority of in-house development;

• Use J2EE framework where possible and make sense;

• Use C++ for server application (if necessary)

• Use CORBA as primary integration framework;(there are tons of reasons and I am going to talk about that in separate document about Java and Security Infrastructure)

• Expose limited functionality as WebServices if necessary (it is matter of configuration, almost ZERO efforts required if some functionality is already accessible via RMI or CORBA)

• Do not be WEB-oriented as WEB is just one (limited) way of communications. We should not name Web Services with the name because it misleads us. Proper name would be Internet or Public Services.

• Define own set of requirements and do not derive them from vendor promises and white papers.

Thanks,

Konstantin Ignatyev