Wednesday, October 21, 2009

Development

I'm not a developer but as the team leader of the sysadmins (which is often referred to as the "technological team") in my department I am interested in the platforms and methods that are used for development, after all the bottom line is that I'm responsible for the stability of the systems and a system is more stable when the correct practices are used.

Let's take for example our Oracle ERP system (which I used to administer so I'm more familiar with it than with other systems). Today we have web applications based on different technologies:
1. PL/SQL cartridge based applications - well, the programmers do know PL/SQL so it's kinda OK, but no new applications are written using this technology and in the next EBS version (R12) it's no longer supported.
2. Java based applications - no one really knows them and they're supposed to be re-written.
3. ApEx based applications - small modifications are still made to them but the knowledge level is pretty low.
4. .NET based applications - that's the technology that all the developers are familiar with and with which the latest applications were developed.
We have all those techniques since each of them fitted a different need at a different time.

One technology we don't currently use is the Oracle Applications Framework which is a pretty strong technology but...
We currently have about 3.5 EBS developers none of which is really specialized in Java (and the Framework is Java based) and the turnover rate in the developers' team is pretty high.
These facts don't really get along well with the multiple development techniques we maintain.

So now it seems like the time to make a strategic decision as to how the EBS development will look in the next few years, I can think of two main approaches:
1. We choose one single technology that we'll use to write all the solutions, obviously it won't meet perfectly all the needs but the programmers will be specialized in this technology and training will be relatively simple.
2. We choose two technologies that will answer two major types of requirements - for example general user applications vs. specialized user applications. The programmers will be less specialized but we'll be able to provide better solutions.

Anything more than that will have too much training and maintenance overhead...

7 comments:

Unknown said...

I have SOOO much to say about this post, that I can write a series of posts of my own. But I guess you kinda expected this comment from me.

If I know the subject well enough, the first four technologies you discuss about were chosen at times for being "just this one technology". You can't predict what technology you'll need 3 years from now without guessing and having a crazy visionary person (in the levels of MS's ray ozie). The only thing you can do is learn from past mistakes (and call in for some help :) ).
Finally, consider the fact good programmers would learn everything you'd throw at them, as long as you can back it up. The IT industry usually promotes hybrid approaches (best-of-breed and not best-of-vendor), so fixation on anything would probably cost more in the long or very-long run (e.g migrate from some platform like Notes to something else...).

eliazu said...

who's this half EBS developer?

eliazu said...

:)

Unknown said...

Moshe already said the smarter part of my comment so i'm only left with the silly one - it's technology "stack", not "cartridge". Seems to have irritated me from half across the globe :-)

Unknown said...

Actually Yevgeny, the usage of "cartridge" is correct. "PL/SQL cartridge" is the name of the technology that bridges between the Apache web server and Oracle RDBMS. Don't be irritated :)

Unknown said...

I stand corrected. Learn something new every day... :)

Unknown said...

Thanks for the backup Mosh. Doc, it's good to know you still care about this kind of stuff :)