What if I Don't?

What if I Don't?

I was asked if I could comment on things that didn't work when building an architecture team. I'll start with a quick synopsis of what happens if you don't do the foundational items I recommended in my previous article. Most of the recommendations came as responses to issues we encountered because we didn't do the foundational work and jumped right in to "doing architecture".

If you don't have a charter, your team can lose focus on what they are trying to accomplish. Many architects have strong skills that are easy to apply fighting fires in the organization. In one case, the architecture team spent most of our first year just dealing with those fires and not creating architectures that would enable us to prevent the fires in the first place. By having a charter, the team can ask leadership to help prioritize their efforts.

Without identifying customers and needs, it can be difficult to know what to prepare for or communicate the value of the architecture team. This customer list is also important for outreach and advertising of the team's services. I can think of several times where we weren't clear about who our customers were and what they wanted from us, causing us to be reactive to demands instead of proactively addressing their needs.

Without a menu of services, every architecture activity is bespoke, making it very difficult to bring on new architects or ensure consistent delivery. By having a menu, your architects have a better sense of what to deliver for particular customers. This menu also lets you align your architecture work with the team's mission and goals. Several times in my career I have been part of teams that skipped this to later discover that doing the work that mattered most to achieving our goals. I have also seen architecture teams that struggled to communicate their value to the organization because they couldn't clearly articulate what they produced, how often, and for whom. "We do architecture." isn't very informative.

I once worked for an organization that had 15 different roles with "architect" in the title. Many of the people with these titles were engineers or analysts that had reached the top of their respective job family, but didn't do any architecture work. By creating new titles, we were able to identify people who did architecture.

The list of "things we've done that didn't work so well" includes:

  • Picking an architecture framework and modeling tools too soon
  • Jumping in to "do architecture" with the expectation that everyone knows what it means or why it's valuable

I'm sure many of you have other stories to share.


要查看或添加评论,请登录

Jereme Kuperman的更多文章

  • Agile Modeling

    Agile Modeling

    Over the years, I have struggled with incorporating modeling and architecting activities into Agile development…

    2 条评论
  • Modeling Stakeholders and Concerns

    Modeling Stakeholders and Concerns

    Model-based Systems Engineering (MBSE) is the formalized application of modeling to support system requirements…

    2 条评论
  • Concerning Stakeholders

    Concerning Stakeholders

    I can get everything I need from the Swagger docs. I don’t see the point of all that other stuff.

  • On Architecture Frameworks

    On Architecture Frameworks

    It’s time to “do architecture.” However, if you or your team are just starting out, or you are working with a new…

  • Paradigms for Contracted Code Ownership

    Paradigms for Contracted Code Ownership

    The bulk of my career has been developing software systems for a variety of customers (Government and private sector)…

    1 条评论
  • Building an Architecture Team

    Building an Architecture Team

    In my career, I have had several opportunities to stand up architecture teams. In the process, I have learned things…

    4 条评论

社区洞察

其他会员也浏览了