As organizations create new products, grow their workforce and add new teams, keeping them in sync becomes difficult. This becomes even more challenging as the demands of a fast-paced marketplace require greater agility and flexibility. Throw in the growing complexity of technical solutions, service-oriented architectures and dependencies between teams to deliver pieces of a larger feature and it feels miraculous when something is completed.
Many IT departments establish a central enterprise architecture group to help ease these demands and ensure a common technical approach across the teams. This centralized approach to creating high-level technical solutions is nothing new and has been used for decades.
In many organizations a stigma exists between the architecture group and delivery teams, primarily with developers. This often occurs because there is architecture “push.” Architectural push means a team requests a technical solution or approach from the architecture group and waits for a technical decision or direction to be delivered to them. The direction is often received after the team really needs it.
In an organization striving for increased agility you know you are in a state of architectural push when these symptoms emerge:
Lengthy or cumbersome sprint planning sessions. Creating tasks becomes arduous as the ambiguities of a proposed technical solution are greater than what is actually known. No one knows quite what to build so tasks become vague and irrelevant.
Out of flow sprints. Sprints are being interrupted as constant technical impediments emerge or technical decisions change mid-sprint.
Out of control dependencies. Everyone is waiting for everyone else. Building a release plan with any confidence becomes challenging if not impossible.
Stressed-out product owners. The frustration level of the product owners becomes palpable as it becomes harder and harder to release valuable features to their customers.
A plethora of hacks. As pressure builds to get something out the door the team will do whatever it takes meet their commitments. This includes short-term hacks which will rarely be removed and will ultimately make things even more complex in the future.
One solution, of many I’m sure, for organizations seeking greater agility is to provide an enterprise architecture vision crafted in parallel with the organizational and product vision. The architecture vision will answer the question “What technical capabilities, comptetencies, and capacity do we need to deliver on the vision?” As the name implies, an architectural vision will require forward and aspirational thinking.
With a well-formed and updated architectural vision, teams will begin to gravitate towards the vision because of the value they receive by knowing they have a clear runway to deliver on commitments.
A team pulling from an architectural vision will begin to:
Build trust. The team should know the stories they are committing to is feasible and not fraught with technical land mines.
Build mid-term confidence. By intertwining technical and product visions (and roadmaps), the product owner begins to establish a partnership with their architect. The architect become an advisor instead of an architect when crafting the product vision.
Reduce long-term complexities. There should be a reduction in technical hacks and short-term solutions as strategic technical solutions are imbedded into product planning. Technical upgrades are also introduced into the product roadmap to ensure time is allocated for these important activities.
One approach is to embed a technical lead (or architect) on the team with the product owner. The technical lead would be the conduit into the enterprise architecture vision. You can find a little more about this approach here.
One reply on “The Gravitational Pull of an Enterprise Architecture Vision”
[…] and investing in techniques to drive technical excellence. Enterprise architecture can also help by intertwining your architectural vision and roadmap with the product vision and roadmap. This helps by implementing technical capabilities in advance of the needs of the product (instead […]