Showing posts with label enterprise. Show all posts
Showing posts with label enterprise. Show all posts

Wednesday, 22 November 2006

So, what IS 'enterprise'?

Time to bite the bullet, I guess. What do we mean by 'enterprise'?

Consulting the Oracle, more formally known as Wikipedia, we find, in the Enterprise software entry:

Enterprise application software is application software that performs business functions such as accounting, production scheduling, customer information tracking, bank account maintenance, and the like. It is almost always hosted on servers, and is used by multiple employees of the same organisation. It can also be any software application hosted on a server which simultaneously provides services to a large number of users, typically over a computer network. This definition contrasts the more common single-user software applications which run on the user's own local computer, and serve only one user at a time.

Actually, y'know? That's not bad. The first half is the 'traditional' definition of 'enterprise', perhaps, but I want to zoom in on the bolded sentence: "It can be any software application hosted on a server which simultaneously provides services to a large number of users, typically over a computer network.". The main reason I'm aiming for that is that it then covers not only internal CMS's, publishing applications and the like, but also end-user facing systems (such as, for example, Amazon or Flickr).

Let's take that second sentence as our prototype definition, and dissect it to see what it implies. I'm very aware that I'm reaching, just a touch, with some of this, but it's a very good jumping off point to allow us to reach a definition of 'enterprise'.


"...software application..."

It may seem odd to pick this one out, but bear with me. Implicit in this is the concept that it's something you can point at and say "this was built to do X". In and of itself, that's perhaps not much, but what follows on from this is: its functionality is well defined, and from there, it's a very short leap to saying it is designed using good software engineering principles.

"... hosted on a server..."

Instantly this implies it has a client/server architecture of some sort. Maybe its true that most of such applications will have a web browser as their client, but let's not assume that: a mail server is just as clearly an enterprise application.

"...simultaneously provides services... "

I dunno about you, but to me that screams a requirement that the software is thread and transaction safe - no one user's changes should be able to overwrite another's.

"... to a large number of users..."

Following on from thread and transaction safety, that adds to our requirements the obvious one that it must be scalable.

"... over a computer network..."

Again, a little bit of a stretch, but that phrase should ring alarm bells in any sysadmin's head. It should be secure against unauthorised use.



How's that?

Monday, 20 November 2006

LAMP++?

Writing the previous post raised a number of thoughts while traversing the London Underground, which will keep me going in blog entries for a while, I think.

So... LAMP.

Linux, Apache, MySQL, and Perl (or PHP, but I kind of promised myself this blog would be mostly PHP-free. :) ). As characterised by O'Reilly's excellent OnLAMP section, in fact, which is recommended reading, and a champion of the cause.

Is this Enterprise Perl?

Interesting question. I think the answer is, sort of: it's its skeleton. It's the bones on which you can build an enterprise-level application in Perl. (Which reminds me - we still need to define exactly what we mean by that troublesome term 'enterprise', don't we?) But it doesn't actually define anything. A single CGI that uses the HTML generation methods and talks raw DBI to MySQL is as much LAMP as a fully OO MVC-style web application written in TT2 and DBIx::Class.

It clearly can work, though: Yahoo's internal CMS is written in Perl, so's IMDB, Amazon's publishing system, the entirety of CricInfo (trust me, I designed it - it's a TT2 fronted MVC web app, or at least it was when I left)... all these can be pointed at as examples of LAMP-done-well, and cover four of the biggest sites on the web (even CricInfo - a quarter of a billion page views a month on a single sport site). OK, so the 'L' occasionally stands for FreeBSD, but we'll draw a view over that - the spirit of the 'L' is 'Unix or Unix-alike on x86 commodity hardware', and we can let Yahoo off, just as we can excuse the folks who use Postgres. But there's really more to these than LAMP, or at least, we hope there is.

What we're looking at, from an enterprise point of view, is something I'm going to call LAMP++. I'm sure, with a bit of work, we might be able to come up with a better acronym, but by analogy with C++, LAMP++ is actually not that far off the mark. The '++' means we're talking adding, or rather mandating, an OO approach to Perl (including an OO DBI abstraction layer), some form of templating, be it TT2, Mason or whatever, and some form of Apache-embedded Perl interpreter (mod_perl). We're looking for Perl programmers, not scripters, and we'd probably really like test-driven development, too. We're taking as our bible not the Llama and the Camel, but Perl Best Practices and Intermediate Perl, and to guide our philosophy we keep handy Perl Testing: A Developer's Notebook, and Perl Design Patterns.

LAMP++. It's got legs, I reckon. More anon.

Tuesday, 14 November 2006

What IS 'Enterprise'?

After a particularly brain-numbing hour attempting to persuade a development build of our main web site's Perl back end (on Debian) to actually run on a co-located RedHat Enterprise License server, I wondered aloud, with a degree of frustration, "So what the heck does 'Enterprise' mean, anyway?"

Our sysadmin, who is prone, like all of his ilk, to disparage any and all instances of rampant abuse of buzzwords, offered that it meant, among other things, 'very very slow, uses XML unecessarily, and comes with a default configuration that's no use to man nor beast'.

Mischievously (for reasons perhaps to be explained in a later blog entry), I suggested that that could be summed up in the four letters 'J2EE'.

One of my Java-savvy colleagues (in fact, all my colleagues here are Java-savvy) opined that that wasn't exactly fair, and that 'J2EE' wasn't really anything more than shorthand for 'go read this 400 page document on The Right Way To Do Things'.

Interesting.

I'm in the minority here at $CurrentEmployer, since I /am/ the token Perl developer. But this, and a whole load of other things, have got me wondering. Why isn't there a 'Perl Enterprise Edition'? Maybe there is, and I'm missing it? What would it be, anyway? Perhaps the question is, where's that mysterious 400 page document that tells us what it is?