How to organize EA team.
What is the best way to organize EA team in a company,
if you have multiple teams working on multiple platforms/languages.
Assuming each team is divided into 3 groups,
1 for UI
1 for Business and
1 for DataLayer.
Is it better to have 1 EA team for all the teams in a company,
where ea team will take care of the service layer and
the rest of the members in each team will implement the UI layer
of each project.
Or Would you borrow each member of business layer team from each team to be a
member of EA Team implement the services and messages.
Just wondering if any one has any suggestions.
Thanks.
[658 byte] By [
Sailu] at [2008-1-3]
Both cases has pros and cons.
In first case, the "moderated" EA team may be "out" of the domain area, and solution may go to the wrong side.
On the other hand, taking the second approach - one person from the domain area, you can end up than people are realy good specialists in their area, but know nothing about EA. Moreover, these guys, from different team, maybe not very good teamplayers, if u put them together.
So, the best case will be summarizing these approaches - you have a team of EA experts and add one member from each area UI/BAL/DAL who knows the domains the best
I think it's optimal solution
Indeed,
having a separated EA team for the whole portfolio of applications in the organization (that includes those the company acquires, beside those the company build directly or pay some ISV to build) is not a bad idea but they should drive goals related with IT alignment with the business needs, gathering early feedback from the architects on the different projects about how realistic -considering each project as a basis- are those goals in terms of implementation
A typical example, nowadays: the decision about turning to a service-oriented architecture (SOA) could be seen as a corporate strategy. However local issues like identity management (SSO, etc), master data management, etc, must be checked with the lead architects of each project in order to figure out "when" will be a reality, "how much" will it cost, etc
Hope it helps
Sailu,
My view on this is that you need to do whatever allows proper communication between the groups.
I'd say that you really need to have a group across all the different aspects of the team, otherwise there will be a disconnect. Information will not flow freely, and design from one group may not gel with those from another.
I've always worked under the assumption that to an extend more heads are better than one, so I wouldn't have a single solution architect over everything, I'd prefer a team, and for that team to work closely with the domain teams that you describe.
Borrowing a team member from every domain would help, but only if that person can represent the views and knowledge of the whole domain team. If they can't it might be better to have brainstorming sessions with each domain team at the very least, and then on a more regular basis have that one team member involved in decision making. Those team members really have to be good at communication, and also be able to work with both the team from which they come from and the EA team in which they work with equally.
There may well be knowledge known only to members of each domain team, information which could make or break an architecture, you need the involvement of those people, and ideally their buy in through involvement in the project to make the solution work well.
Obviously you have to draw the line somewhere with involvement, which is why I suggested brainstorming groups. You could also then have presentations to the domain groups on progress of the architecture, and get further feedback, support and verification.
I think that this sort of a set up allows everyone to know what each other is doing to some extend and can enable and empower those people to come up with great ideas to help the architecture and the project as a whole.
I hope this helps you start thinking about how these decisions will affect your project in the long run,
Martin.
Sailu,
I assume what you mean in any case is that the EA is involved in the design and the code is implemented by other team members. If that is the case, Diego's post explains it pretty well. Specially in the case you describe, where the team members of each project are divided by technology, you really need an EA team to keep everything aligned to business.
Regards,
Freddy Rios
From our humble experience, we are a team of 4-8 architects for a company with 600 devs.
First, their must be architects in each account, or at least 1 architect for each domain (business vertical).
Secondly, for the DAL we use a code generator company wide which generates code according to a certain templateand based on enterprise library, that way we garuntee that we have the same architecture for the DAL.
Third, we have design consultancy for each project attended by the dev leads and at least 1 enterprise architect to brainstorm design.
Fourth, We conduct an Architecture review mid-project just to make sure everything is aligned.
Some tips:
1. Use software factories as much as possible (basically as much automation as is feasible)
2. Have a library of resusable components/modules for the very common tasks e.g. (user management, UI... etc).
3. Promote Architecture alignment through regular sessions with designers.
4. A wiki/internal site/discussion forum for exchange of ideas and common reccomended patterns and implementation.
These have worked very well for us so far, I hope they will be of benefit to you.
All are welcome to comment.
