Given current popularity of Agile development methodology
and concomitant need for enterprises to have an architecture. "Grass
roots" approaches are good but they need to occur within a larger, overall
structure to the garden. If not, as a whole you wind up with an expensive mess.
What looks like a thing of beauty within and to the individual Agile project
team, might in fact be - when looked at more globally - an unmanageable
eyesore. Even for individual Agile project, software quality is more often
caused by poor design and architecture than coding. Thus, what’s EA role in
Agile project, should they have a specific person assigned as the architect in
Agile team? Should such architect role be shared between different Agile teams
in order to maximize his/her value? Or for larger projects with several Agile
teams, should they also have a “Chief” EA over the other software architects? If
so, what are his/her responsibilities?
1. Software Architect at Project Level
To be successful, there is a need for a project level
"architect" who comes from within the Agile project itself - who is a
member of the development team. But that person needs to work well with
whichever architects are responsible for the larger scope.The Agile project must
live within the constraints defined by the larger architecture, the design of
the whole garden, not just one corner of it.
Scrum masters are responsible for the communication with
what is called the Product Owner. A Scrum Master (or project manager) in some organization only covers one product, The Product Owner decides the features
and overall priorities and stands between the Agile Teams, the client and the
business executives. The role of
Software Architect is covered mostly through the process and across roles,
since the idea of Agile is to stay away from refining things top down and
decide on exact approaches as a team only for each Sprint or each iteration.
- Ideally, a Software Architect is one of the best in the team and should be involved from day one, minimizing risks by building early on in the project and setting out Architecture directions and coding directions. But then, most important is that the Software Architect keeps on involved and CHECKS if his/her directions are followed and being involved in planning too as at first he/she knows the qualities of the team members and also he/she is the person to make the trade-off between time, money and architecture.
- Typically, Agile methodologies such as Scrum or others call for a Sprint / Iteration 0, which is where typically the design for the rest of the Sprint / Iteration is done. Architects should be the primary drivers of this phase and serve in consulting roles throughout the rest of the Sprints/Iterations. So what's the role of the enterprise architect? It is to advise the Product Owner during Sprint 0 of what architecture items are needed on the project backlog, and to help everyone understand during sprint reviews how well the project is conforming to the architecture. The architect should also be available to the Team as an ongoing resource to help accomplish the tasks the team defines for itself.
- The Software Architect should have this role because his/her colleagues see him/her as the Software Architect, meaning he/she is well respected, has leadership qualities to align people and above all he/she is knowledgeable because he/she develops and has made mistakes in the past that he/she has learned from. Software Architect work well in large projects with multiple scrum teams that each work on a different aspect of the product, and on one-team projects.
2. EA at Enterprise
In order to have a scrum team follow or contribute to
architecture, there must be a clearly pre-defined Enterprise Architecture in
place. And the EA, or more likely, the Business Architecture component of the
EA. As the problem with democracy, though, is that it must be applied universally. That is, the Business Architecture must be built and endorsed by democracy based governance process representing. Scrum requires a major cultural shift by an enterprise that does not already entrust decision making at the lowest levels of the organization is a valid pursuit for the Product Owners. The Product Owner must be
committed to the architecture that a project needs to follow. That only works
when the architecture is owned by a governance body representing the Product
Owner.
- At enterprise level, a seasoned
architect can really set the direction of the technical efforts as
well as having an overarching vision, and you should have the development
methodology that best fits the project, and not try and cram every
development effort into the scrum box because it is something 'new and
exciting' And more software
architects under an "Enterprise architect" working closely with
each project team acting as a liaison between the team and the Enterprise
Architectural function.
- The architecture function on a company level should be an independent entity, allowed to work outside the Agile team. In order to maintain consistency in a companies product lines with respect to architecture frameworks, coding guidelines, end-user documentation, GUI look and feel etc, then it is important to have a set of standards both the teams and the top managements' backup and respect. Enterprise Architect (or Systems architect depending how you understand the different types of architectures) will continuously keep track of the product backlog (looking for potential new technical spikes) and also follow up major technical concerns (such as reuse, compliance to reference architectures, alignment with business and so on).
- Having clear, well defined ("well" does not mean reams of useless of paper) reference architectures provided by the Macro Architects - as well as having meaningful designs/models exposed by the Agile team for sign-off at appropriate junctures. The point is not to review the internals but the subsystem interfaces, technologies, standards adherence, etc, Although it will certainly evolve, ideally some kind of minimal design is worked out, exposed, and reviewed up-front toward the beginning of the project.
3. Agile Approaches Rely on Evolutionary Design
The problem that arises in software quality is lack of
responsibility for the architecture and design. Regardless of the methodology
being used, proper design and architecture practices should be followed. Agile
approaches rely more on evolutionary design but without being grounded in
proper architecture guidelines and best practices, they tend to fail.- Agile is only an optimal engagement strategy in the right environment - it is a productivity tool to an experienced development team and with a willing / understanding / sophisticated customer. It is pointless to 'scale up' a team until there is a common foundation of
2) process / methodology / standards / configuration management etc
3) and sufficient stable backlog of the domain requirements
- Communication is key: Depending on
the project, but above all it is important that Software Architects talk
to each other, and perhaps even do peer reviews. The right level of
empowerment (tools, business process adherence and insight) allows
architects to work across and track projects concurrently without
compromising required rigor.
- EA Quality:
1 comments:
The customization should be done in a way that is sustainable without a consultant going forward if at all possible.
Post a Comment