EA was around before this of course, namely through the introduction of the Zachman framework in the late 80's, early 90's, but most organizations hadn't adopted it yet. The federal mandate provided an excellent incentive both for federal and commercial adoption. It also created some issues however, namely that much of the early work in EA became tied to a more procedurally intense form of practice - in other words, to many it seemed to be a bit bureaucratic in nature. The perception quickly became that EA was not an easy undertaking or something that could be used to produce quick results. This is similar to what happened to E-learning at roughly the same time for about the same reasons - government adoption and stewardship was both a blessing and curse to the industry.
So the following question is now often posed within IT in regards to Enterprise Architecture - is it possible for EA to be Agile? In most quarters, the immediate reaction would be a resounding - no. But perhaps maybe we're being too harsh in our initial judgement. First, though, we need to define what Agile would mean in an EA context:
- It would require rapid turnarounds for designs and decisions.
- It would require the ability to integrate both with traditional (waterfall) methodology and Agile development methodology.
- It would need to support and promote collaborative problem-solving within the organization using it. In other words, an EA group doesn't become another island or silo, it is the mechanism that bridges all of the silos.
- Aligning User Stories, Use Cases and Requirements
- Integrating Design & Architecture
- SharePoint as an Architecture Repository
|EA provides the superstructure within which all other enterprise capability resides and interacts.|
Many of the articles included in this blog were produced from projects that followed an Agile EA approach, including the Intelligent Healthcare framework, Semantic COP and Governance as a Service. I've applied Agiel EA in the following domains thusfar:
- Data Management
- Services / application design
- Portal / CMS
- Clearly defined expectations for the both what the EA group or architect must accomplish.
- A willingness to improvise rather than following industry patterns or methodologies too closely.
- The ability to work to deadline - to engineer a design around the constraints.
- A willingness by the organization to allow the silos to actually work with one another (with an architect as mediator) - this is far less common than you might imagine.
- The ability to develop architecture that is easily translatable and traceable to implementation level designs. In other words, alignment of all design related efforts must be built into the Agile approach.
- The ability to make decisions quickly.
- A willingness to experiment. Many architects and organizations make the mistake of separating EA into a logical or somewhat abstract exercise and not allowing it to be involved in actual prototypes or POCs. The best way to ensure that key design decisions make sense is through an understanding of the technology in question.
copyright 2013, Stephen Lahanas