API ManagementFrom Omnichannel to Customer-CentricityMobile APIs

Why Can’t We All Just Get Along?

Developers, architects, and analysts often need to collaborate in delivering new solutions such as mobile apps and APIs, yet firms often struggle with breaking the silos to achieve the kind of close cooperation they really want – each role sees their objectives in somewhat different terms, and doesn’t really understand where the other roles are coming from. I often see that:

  • Developers just want to deliver the best app or API for the problem at hand, while
  • Architects care about delivery but also aim to serve some longer-term goals like promoting cooperation among teams on design patterns and shared APIs and services, while
  • Analysts want to do a good job of representing business stakeholders’ interests throughout the process, but may be torn among competing interests of different business leaders.

The more time each role spends working out of contact with the other two, the harder it is for them to understand the other two perspectives. Proponents of Lean and Agile practices correctly point out that the answer is to work more closely together, on cross-functional teams, but that’s really only part of the answer. Even with that solved, these broader teams often find that:

  • Each role still has somewhat different objectives, and often use very different tools to achieve them.
  • When the emphasis moves from handoffs between groups to collaboration on shared work, the roles’ different tools and backgrounds become even more apparent.
  • Analysts may struggle to deliver “just enough” requirements and acceptance criteria to fuel the next sprint or scrum, if they have been trained to use techniques such as Use Cases, process modeling, or customer journey mapping, which have a broader mission.
  • Architects may find it hard to package design pattern guidance in a form that developers can quickly absorb and benefit from.
  • Developers may have different ideas of what they want those team members to work on, wanting analysts to define and perform user acceptance tests, and architects to work on thorny technical design problems.
  • The day-to-day process each team member follows may still fail to include other team members’ perspectives as often as it should, unless that process changes to emphasize each role’s participation in an optimal way that leverages each person’s strengths.

At DigitalML we see our customers dealing with some of these same problems, but making progress on solving them using the ignite Service Design Platform as a basis for a more collaborative way of working. Part of the secret to making this work is the automation ignite provides – it makes the good path into the easy path, so everyone wins!

What does that mean, exactly? It means that:

  • Architects can package their knowledge in a form that development teams can easily directly consume and use to build the APIs and services they need to deliver their apps.
  • Analysts can more easily add value because instead of trying to package their requirements in Word or Excel files that someone has to (hopefully) read and follow, they also work in ignite, creating design artifacts that developers consume directly.
  • Developers can jump-start their work by consuming design artifacts directly, using the generation and automation ignite provides to get right to work on APIs and services that otherwise would have taken weeks to design by hand.

It’s great to go fast, and we love hearing customers say that a design stage that used to take weeks can now be completed in hours. But the value of collaboration is just as great, because it drives significantly increased reuse, eliminating redundant and needlessly disparate implementations that would have driven up the cost of runtime infrastructure, maintenance, and enhancements. Ratios of 2-to-1 or 3-to-1 in service portfolio rationalization are not uncommon when collaboration drives out needlessly redundant work.

Whether you choose to use ignite or not, you should aim to establish this kind of collaborative working among your architects, analysts, and developers, getting everyone on the same page using common or at least well-integrated tools. We just happen to think we have the best solution for accomplishing that goal!


Related Articles