Design, buzzwords, and the beginning
by e. sammer - email@example.com
I am not an authority on enterprise application design. I'm not even sure if there is such a thing. There are a handful of people in the software development community to whom we look for the fresh ideas and concepts we will use in our next major project. I tend to think these people have the talent to step far enough away from the letters to see the DNA, so to speak. What's interesting here is the pseudo-philosophical methods they, either knowingly or not, employ when breaking things down into topics worthy of our hard earned $50USD at the local book store. Thank goodness we have them. (The people and the fifty-spot, that is!)
I'm a fan of this aspect of software development. Don't
get me wrong, I love writing code, but there's still
something about being able to construct a system that
can be bent, extended, coerced, and even convinced into
doing things not originally planned at the time of its
conception. Given the choice, I would spend my time
working on frameworks, libraries, IPC mechanisms,
distributed communication systems, and (dare I say)
middleware rather than whatever the end user perceives
The Application™. It's a bit of an
odd place to be, at times.
I have found, though, that while there are many people interested in the technology behind the bigger buzzwords (SOA, ESB, EAI, web services, middleware, modeling, etc.) most find the overarching subject matter to be daunting. Learning what something like middleware is doesn't necessarily provide one with the requisite knowledge to know when and where it's useful and why. In fact, some, if not most people tend to have their grey matter further warped by the marketing efforts of some of the companies that compete within this space (or want you to believe that they do). Have your ever heard of someone's e-business actually being synergized and forming a new paradigm? Doubtful. There are buzzwords and then there are the software and (gulp) services companies. Run for it adventurer; here there be dragons.
Forget the buzzwords. Even if you learn what they mean
(and it turns out that some of them do in fact mean
something), the honey in the hive is how they work
together. This is all about the sum being greater than
the parts (or however that saying goes). The thing to
concentrate on is the goal. What are you building? What
should it do? Who's going to use it, and more
importantly, what do they want or need to get out of it?
I think the CTO I work for would ask
what is the
business problem you're trying to solve? And, he'd
be right. Remember that how the problem is solved should
(but may not always) be the last thing to think of.
Remember when Really Smart Person #324994 said
when your only tool is a hammer, everything looks
like a nail? It's true.
So throw out your hammer. Trade up for the Bat-person utility belt. There is a toolbox made by some of the smartest people out there. In that toolbox, there are architectures that facilitate processes, that orchestrate systems, made up of applications, which is really just code, which is structured sets of design patterns, which can also be applied to everything back up to architectures. Or, uh, something like that.
So where do you start? Right where you're standing.
Someone once told me,
You're exactly where you're
supposed to be. Other than obtuse and irritating to
hear when you feel like the question still isn't
answered, it's also very true.
I plan on posting here some of the more approachable papers I've written (and will write) about what the software world calls enterprise class design (or enterprise application design, or system design, or application modeling, or system development, or whatever else they feel like selling it as today). Maybe it's better put a different way; this is interesting if you answer yes to a considerable number of the following:
- Is this a custom core application that is used, in some capacity, by everyone in the company?
- Is it hard to define the boundries of
- Are there multiple logical segments to the application? A web interface, an API for clients, an import / export system, a reporting system, a monitoring system, an administration system, etc.?
- Do you need to integrate with clients or third
parties and get things to
play nicewith them?
- Do your parents understand what your company does? Do you?
We'll explore how design concepts, design patterns, architectures, and other things collaborate and form an enterprise system. We'll talk about examples and real systems, commercial and open source products, processes to make your life easier, and good resources for learning more.
Was this interesting? Are there inaccuracies? Could it be better? Do you want to contribute? Send me your comments.