|
I was having some deep thinking about what I call, disdainfully, "enterprise architecture", those bloated multi layerssss (the more the merrier) monsters... When it suddenly hit me how it might make sense in some environment. And I am looking for feedback on my conclusions.
First I came from the point of view of an experienced developer who has mostly worked in small teams and I personally find that a vertical approach to development gives better results. i.e. When one is in charge of a feature, one does the SQL, the data exchange class, the webservice, service proxy and the UI and/or whatever else is needed for the feature to be fully functional. If one don't know how to solve a particular problem, ask a colleague! And as for code reuse, regular chat with your colleagues make sure every body use some common utility (or even business utility) library whenever possible. I think it gives better overall results.
But now, for an other point of view, if I imagine an environment with high turn over and lots of graduate who don't know very well how to do SQL, HTMl/MVC, WPF, WCF/WebAPI, etc... Nor do they talk to the customer and understand the feature they are working on very well... It might seem like a good idea to have a GUI team, a SQL team, a Business layer team that each focus on one technology and one layer. Hence the layer monster comes to life with some reason to be such.
Not that I agree on the long term benefit of that approach. But it kind of makes sense in that light.
Am I on track here, as to why enterprise architecture is so wide spread?
|
|
|
|
|
And there was me hoping you were on about the Star Trek movie out on Friday... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Haha!
You mean the markings on the ship?!
Sorry! 
|
|
|
|
|
The important point is that each layer be independently unit-testable and only communicate through defined interfaces. Once you have that your sub-teams can operate independently and still create a coherent end product.
Of course something like MVVM (or event better CQRS) gives even better sub-team independence.
|
|
|
|
|
In larger companies: yes, very much so. And there's also the possibility that one of you management went golfing with a sales person from Oracle and now you're stuck exchanging your SQL server code with Oracle code. Which is easier if it lives separately from everything else.
Also: a lot of developers don't want to work vertically. They don't want to do GUI or SQL work. Is it ideal? No it isn't, but with the shortage of good developers that want to work for big companies, there is not a lot you can do about it.
|
|
|
|
|
Jeroen_R wrote: Also: a lot of developers don't want to work vertically.
Really?! 
|
|
|
|
|
Yes. Sad, but true. IME, it's mainly employee developers who stop learning and just come in from 9 to 5 that become like this, though.
|
|
|
|
|
You mean those of us who have kids and a life outside of coding?
|
|
|
|
|
Yes, that is indeed the reason I hear a lot.
Note: I have 2 kids, a wife, hobbies and I still find the time to stay more-or-less up to date with technology. It isn't that hard...
|
|
|
|
|
That's why I read Code Project, among other sites\newsletters, so I can stay up with technology.
I had a supervisor who seemed perfectly content to just come in and do his job everyday. It's wasn't because it was hard, he just was more interested in other things.
|
|
|
|
|
I have seen this issue in particular in unionized IT shops. One place I worked at, the IT employees (20+ years, coming from mainframe/COBAL development) had maxed out their company benefits, and had no further incentive to learn any new skills (such as web development, among other things).
As an IT Professional/Contractor, it is critical for me to keep learning new technology skills as they become relevant. This is not unlike other professions, such as medicine, engineering, etc.
As far as those "enterprisey" patterns, it might feel like overkill for smaller projects. But I have yet to work on a project for a client, where once it was finished they wanted a new set of features on it. By using these sorts of patterns, you keep the system flexible enough to add these new/updated features without having to do a major refactoring job first...
|
|
|
|
|
It's terribly boring. I'm "the communications and hardware guy" (quoted because it's informal and I still do anything that must be done) and there are months where I have to implement all the new hardware communications and interfaces. After a month my productivity falls... to thep oint I start losing confidence in my abilites. Then an emergency arises and I solve it in record time - basically doing the same kind of work over and over dulls me to the point of uselessness.
Also vertical works are always clunky, integrated and customzed environments work better - that's why in manifacturing plants verticalization is very loose and broad and the systems are basically ad-hoc solutions with nothing similar to layers, they are more like interconnected clouds of components which try to expose the same interfaces. They usually are more flexible, at the cost of greater complexity in the system.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
There's that famous saying: "Coding's more fun when your horizontal"... something like that anyway.
|
|
|
|
|
|
I usually warn if something is outside my main area of expertise but stop against nothing. In 4 years I did VB6, C++, Assembler, C# and C++\CLI.
If soemone asks me C# things I clearly state that I have very little experience in C#, especially good C# (nobody uses it where I work and we have no code base in C#). Then I start working on it.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
Yeah, I do that too. "Sure, I can have a look at it, but it's all new to me. So if it's in a hurry..." something like that 
But just saying "no, I don't do that." is a no-no.
I'm not sure how the guy I just mentioned could've put his incapability into words though, we'd have to invent some new words
|
|
|
|
|
No C#?
poor you...
Anyhow I am not too worry, you seemed to have fun too! 
|
|
|
|
|
Embedded real time systems need performances, to the point that I (being the only Assembler speaking member in the office) sometimes spend weeks optimizing highly used features like rotations, color change vectors appliacations, integer differentiations and so on.
Also it all started in QBASIC some 25 years ago, ported in VB6 and C. The total codebase is estimated in the millions of line of code and we still have to support some old Win2k system. Our developement workstations are painfully slow and rigged with 80 GB HDD and a whopping 1 GB of RAM...
In short there are only reason to NOT migrate to .NET. We will move the graphic interface only to C# and maybe WPF but first we need to move the core elaborations and part of the hardware management away from the interface (bad design, legacy design, PITA to change).
Also all those modifications will work for the future, meaning we will have to support our current branches (over 300) for 10-15 years at the very least.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
A person's actions should always weigh more than their words.
Sander Rossel wrote: I punch them in the face
Somehow, I don't believe this. Just saying.
|
|
|
|
|
I completely agree with you *punches you in the face* 
Alright, I don't really punch people in the face, but not because I don't want too.
|
|
|
|
|
I think I met this guy...
We are talking building blocks or black boxes which can be plugged into each other once they have been made to do their individual function.
It makes sense for rapid development but, as you say, no one gets to see the full picture.
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|
|
The more parts and pieces a machine has, the greater the chance for failure at any given point.
I am highly-against overly complex architectures and designs. I have never seen one live up to the sales pitch, and they have been nothing but a nightmare to maintain.
KEEP IT SIMPLE STUPID (KISS)
|
|
|
|
|
100%. I concur.
Regards,
Rob Philpott.
|
|
|
|
|
Over the years I've learned the following enterprise patterns:
The postpone pattern: useful when decisions need to be made.
The we-will-get-back-to-you pattern: useful for when they don't want to get back to you.
The clueless pattern: very widely adopted in the enterprise!
The outdated pattern: because keeping up-to-date with technology requires decisions and a fraction of the money it costs in the long run to not update.
The XML pattern: because deep down XML is the only technology that's really enterprise ready. XML everywhere. XML 4 teh win!
The save-pennies pattern: the other patterns cost millions, but when you're an hour over budget they'll have your head in a meeting (which costs even more).
The meetings-meetings-meetings pattern: to discuss the issues that arise because of the other patterns (only discuss, never solve though!).
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
