Do agile teams need to work with enterprise architecture authorities?

Some would argue that effective agile teams have all the skills internally to deliver the solution.  Is it practical to expect the project team to have control over all aspects of the project such as architecture, database designs and so forth?  Or should agile teams take some time to consult with authorities such as PMOs (to understand required governance), DBAs (to evolve a common database, or find existing data sources), and Enterprise Architecture groups (to discover existing assets for reuse, or contribute new ones)?

3 thoughts on “Do agile teams need to work with enterprise architecture authorities?

  1. carsonaholmes

    I think it really all depends on the organization. Many smaller IT departments may not even have an EA group. It may be up to the effective agile team to promote good architecture and design and deliver the solution on their own. I think it’s cool when a small IT organization with only a few teams or less starts to collectively promote asset reuse and grow a sense of EA.

    As organizations grow and grow, it’s hard to keep the EA, PMO, Operations, etc. from imposing governance that becomes less and less reasonable and agile. DAD encourages self-organization within an “appropriate” governance framework. Let’s hope this message helps drive lean governance.

    Reply
  2. marklines

    re ” I think it’s cool when a small IT organization with only a few teams or less starts to collectively promote asset reuse and grow a sense of EA.” I agree. That is where the “discipline” in DAD comes in.
    For larger organizations, we need some lightweight/lean governance in place to ensure existing assets are leveraged and improved/extended over time. This doesn’t need to be overly ceremonious. I have seen it be very efficient.

    Reply
  3. Bob Ouellette

    It really does depend on the size of the organization and the type of company.

    My organization has an Enterprise Architecture team. It provides architectural direction on the evolution of our applications/ technologies across the various business domains of the company. In doing so, it helps build out our multi-year plans, establish standards and identify areas for common investment. In essence, it creates the boundary conditions for which project teams to operate within.

    We also provide a “Delivery Support Service”, to enable our project teams to gain easy access to the enterprise standard technologies / environments, leverage common tools and provide them with common services like configuration management, environment management, DBA, continuous integration, build management and tool support. This function works in support of the project team to make it easier for them to adopt and apply our enterprise standards.

    Project teams are empowered to deliver their solutions within the enterprise direction through the support of the Delivery Support Services team. Project teams are encouraged to leverage agile principles and an agile (risk driven) life cycle to deliver their solution.

    So far, I like much of what I have been seeing in DAD.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *