The Old Joel on Software Forum: Part 3 (of 5) - Is Enterprise Architect a real job?

Is Enterprise Architect a real job?

I recently installed the "Enterprise Architect" edition of VS.Net, and the name caused a certain amount of hilarity around the office. But I was wondering, is there in fact a definable set of skills identifiable with the title of "Enterprise Architect", or is the whole thing just a means of making the recipient feel really really important, and of enabling tool vendors to charge staggering amounts of money for their products?

as
Wednesday, January 28, 2004

Enterprise Architect is a UML tool - http://www.sparxsystems.com.au

"Marketing Scientist" is a real job [title], I have a friend who is one.

Walter Rumsby
Wednesday, January 28, 2004

This type of discussion normally disintegrates into the "what is a developer?" and "what is an architect" argument...To which there is no clear answer.

Whether you call them architects, enterprise architects or whatever, many companies employ someone who's job it is to design the overall architecture of an application or group of applications. Normally, I've just heard them called architect.

Mark Hoffman
Wednesday, January 28, 2004

Cue "software engineers" aren't really engineers debate in 5, 4, 3....

Mister Fancypants
Wednesday, January 28, 2004

Those definable set of skills you were wondering about tend to vary quite a bit from company to company. Right or wrong many companies have downsized their entire technical staff except for project managers and individuals who hold lofty job titles such as Enterprise Architect.

In this instance the tool vendor (Microsoft) is simply saying this is our top of line product in this particular category. Not only can Joe the lowly developer use this particular software product but so can Bob your I don't know how to code but I can create great models Enterprise Architect.

In this instance, the joke that your office mates find so hilarious is that in some areas Microsoft simply hasn't put much effort into capturing the lucrative corporate Enterprise marketplace. Visual SourceSafe sucks, they don't sell a requirements tool, and Visio only allows you to draw pretty pictures.

From a developer's POV Visual Studio .NET might rock, however, I doubt most enterprise architects feel the same way about this product.

One Programmer's Opinion
Wednesday, January 28, 2004

As for the UML product, it's called Enterprise Architect because it allows you to model:

- business processes (quite organization-centric)
- features, along with groups, priorities
- use cases (functional [okay, they may s*ck at times])
- domain models (concepts of a business)
- system architecture (layers, sybsystems)
- work at the code level (reverse engineering C#, C++, VB.NET, Delphi, VB, even PHP) & generate code based on your own templates
- depict components assemblies and their interrelations (stuff that you can see in a directory, like .java, .jar, .dll, .exe)
- computers & their links to depict deployments etc (useful in an enterprise setting with development, integration, testing, acceptance and production environments)
- screen flows for guis

It can also;

- generate proper doc (better graphically than all other such packages I know about)
- have source control on the whole thing along with the ability to exchange parts of the model in XML (that works) with your friends
- have a central repository in a SQL server or other db for using it with a lot of people
- really great COM interface so that you can play with all of the repository data the way you want
- a decent price

So, that's why it's called "Enterprise". An Enterprise Architect may be someone able to wrap his mind around all the issues above (meaning: "what do they want to do in this biz and how can we get there with this bunch of technological possibilities in our current environment, how much will this cost etc).

Maybe can you see this as a product manager or something. Maybe a bigger than life role.

Anyway, I am a convinced user of this product for years (I even became a reseller and trainer for it since it was so good after a while). And it works well for my current work.

Of course, the tool is nothing without understanding all of the concepts mentioned above. Pretty pictures are definitely not enough.

So, yes, I think that Enterprise Architect is a real job.

Philippe Back
Thursday, January 29, 2004

In my old company, there were two types of architects. The Application Architect would look at the requirements and come up with a set of rules that the application developers would use when building the system. For example, they would say that component X should be built in the business layer using technology Z.

The Enterprise Architect would serve as referee to make sure all the decisions of the Application Architect would have some common vision or theme. For example, several of our applications send notifications to users, so let's start working on a notification service that can be shared and used for new applications in the future. In addition, the Enterprise Architects would spend time looking at various products and would come up with company standards such as always use DB N and all code should be written in Java and running on J2EE platform M.

The two biggest problems is when all these architects get organizationally separated from development teams. Now you have a class separation where “the other” group always seems to be out of touch. When Architects rise from the trenches, their opinions start to become stale and the trade magazines become their friends. One important aspect of software architecture starts with organizational structure. Keep your key people together.

m
Thursday, January 29, 2004

Or maybe it's meant to be taken more like

VS.NET Entreprise [Edition] [for] [Software] Architect ?

OTOH a job title named "Entreprise Architect" sounds a little strange to me, I would rather call it "Business Architect" - for someone who models business processes, or "Software Architect".

Renaud Martinon
Thursday, January 29, 2004

There's 3 types of people in this world:

1. those who can deliver software. Period.
2. those who can write code, but not deliver the whole package.
3. those that really don't give a crap.

Hermaphrodite
Thursday, January 29, 2004

My current title (not chosen by me, of course) is "Quantitative Software Engineer". Anybody care to venture a guess as to what that means?

Rob VH
Thursday, January 29, 2004

I have a friend who claims he is a "Enterprise Software Solution Architect" and has been out of work for 2 years.

moses whitecotton
Thursday, January 29, 2004

"Quantitative Software Engineer"

My guess is you are in charge of Lines of Code. :)

m
Thursday, January 29, 2004

I'm an enterprise architect for a large retail company. My company just started adapting the Meta Group's EA model. They divide EAs into four seperate categories. Enterprise business architect (EBA), enterprise information architect (EIA), enterprise technical architect (ETA), and enterprise solutions architect (ESA).

I'm a enterprise technical architect, and my job is to take business change requirements and business information requirments from the EBA and EIA, and find the technologies to support them, and to provide enterprise reference architectures that projects can use.

I like the work a great deal, but find it difficult to explain what I do to friends and colleagues.

Patterns Guy
Thursday, January 29, 2004

So, are you saying you the ETA looks at the requirements from the EBA and EIA, then passes them to the ESA?

:)

m
Thursday, January 29, 2004

Yes, in a sense.

The official Meta definiton of ETA is:
"Enterprise technical architecture (ETA): The enterprise technical architecture scrutinizes the
underlying technologies required to run the applications, such as computing platforms, networks,
operating systems, database management systems, storage devices, and middleware. The ETA can be
broken down into specific domains, such as platforms, networks, security, and more."

The Meta model dictates the steps of deriving at an EA model. The business will have a set of high-level business strategies. The EBA will take this set of strategies, and come up with a set of business solution requirements for them. The EIA then takes those and come up with business information/data requirements. The ETA looks at the solution, information/data requirements, and come up either with a reference architecture that can be used if the current technologies can satisfy these requirements, or bring new technologies in house if they are not curretnly existing. The ESA then takes the EBA and EAI's requirements and the available technologies, and manage the IT project portfolio.

I hope I haven't confused you, the Meta model is quite detailed. I'm current doing technology strategies, taking inventory of technologies we have, and what's required by business in 6, 12, 24, 60 months, and try to have a migration plan to have the required technologies in place when the business solutions are required. Of course, this is an interative process, and I'll need to make adjustment to my plan when new technologies become avaiable.

Patterns Guy
Thursday, January 29, 2004