The significance of functional architecture as a competency for APD
“..For that client, it was beneficial to explore the potential product development start-up by spending just enough time pioneering in “the misty forest” of hidden needs before designing and creating a product team.”
Adaptiv product development (APD) is a dynamic field that requires a diverse set of competencies to drive successful outcomes. During three decades, I have experienced that a commonly critical competency is functional architecture. This term is somehow established in Scandinavia (where I`m from), but also having readers from other regions in mind, I’ve learned that it is perhaps most similar to the term business analysis.
In this blog, we will explore the significance of the functional architecture as a competency and where it can come into play.
Why do I call this a competency, not a role?
The simple reason is that I have observed companies experience great benefits by being less locked to role- and specialized responsibilities within a product development team. The way I see it, functional architecture can be considered both as the name of a competency and as a verb. — Meaning that anyone in the context of digital product development might be a contributor to do functional architecture.
I`ve helped organizations shifting towards more simplified org. designs that are optimized for tight, adaptive collaboration between diverse competencies as well as creating a truly shared ownership of the holistic outcome. They actually increased their quality, flow, and speed 🙂
Traditional organization of work, dominated by locally optimized ownership of a task or a competency area, often tends to create a handover- culture. I`ve observed how the combination of a pyramidic power dynamic structure and an extensive handover- culture actually can reduce the cognitive contributions from seriously bright people, — just operating as order- takers. — Unable or uncomfortable to contribute with their bright ideas in regard to functional architecture.
I won’t go all the way down the “organization-of-work- street” in this blog. That topic has of course a lot of nuances and takes both a lot of reasoning and systems thinking to fully address. My point is that I want to create a kind of disclaimer: functional architecture doesn`t have to be considered a specific role. That said, functional architect can of course also be a role and a specific responsibility if it makes sense in the current context.
In the context of consultancy, commonly, organizations want to boost an area of experience-based competency within their product development or maybe just boost the amount of hands-on people to keep up with all the business opportunities. In such matters, it can be helpful to have a name on the competency and by such support a shared understanding of what kind of person to hire.
Why functional architecture?
At the end of the day, most digital product development is all about creating value for customers/ users — supporting their “jobs to be done”, and covering human needs or human problems to solve.
In the context of large-scale product development, I have sometimes observed how some teams are very distanced from this. -More or less every need articulated as purely technical matters, detached from what kind of human need it`s intended to solve. Sometimes the need is not even communicated, — what hits the team (or one of the individuals within the team) is just a task, decided and granulated by someone else and handed over for execution.
I acknowledge that there might be contexts where this makes sense, but I want to make a point of a common frustration expressed by several motivated knowledge workers I`ve worked with on the bottom of an organizational pyramid.
One way or another the bridging between the human needs, the interaction design (if any), the technical builds, and the economical business sustainability must happen. This is where functional architecture comes to play.
Before digging deeper into skills and kinds of work that might be helpful for functional architecture I will spend some lines analyzing the two words functional and architecture.
Functional (as adjective) as defined and exemplified by the Oxford dictionary: “1. practical and useful; with little or no decoration” , “2. having a special purpose; making it possible for someone to do something or for something to happen”, “3. working; able to work (especially of a machine, an organization, or a system)”
Architecture ( to architecture as a verb) as defined by the Oxford dictionary: “To design or put together “.
My intention in seeking guidance from the dictionary is not to be theoretically locked by any means, but rather use them as a foundation for further reflections.
I found this one relevant: “practical and useful; with little or no decoration”.
Here is my perspective on this: In the context of product development, including visual- and or UX- design competencies, the stance of functional architecture might lean more towards the holistic view of what is practical and useful. — Both in regards to the users and to the organization creating something for users. As this strongly depends on the involved people I want to emphasize that this is not by law. Rather think of it as an important area of awareness based on observations in the industry of digital product development. To nuance it further I also want to point out that decoration can of course increase its usefulness.
A pattern I have observed in handover-cultures is that design sometimes is done almost in isolation by roles such as UI-designer and Product Manager with reduced attention to the rest of the functional architecture consequences. I remember in particular one team where one of the developers brought this pattern to the surface in one of the meetings where we reflected on our work approach. Action was taken and the result, by including a wider perspective on functional architecture, was that almost a week of coding-time was avoided and the quality of the user-functionally actually increased.
Skills and kind of work that can be labeled as functional architecture
Maybe perceived vague and obvious, but regardless I still want to highlight the skill of doing thorough exploration of the real user needs combined with a holistic product development thinking.
5 helpful personal skills to support functional architecture:
2. Visualization- and articulation of complexity (On a just-enough level. Often drafting on a whiteboard is enough)
3. Systemsthinking (analytical mapping of cause and effect, but still keeping enough humbleness where experimentation and empiricism are needed)
4. Interviewing techniques (i.e. using open questions and creating a safe environment for the interview)
5. Ability to evolve tech- and domain knowledge/ understanding for the specific context
Curiosity and humbleness will probably be beneficial personal characteristics for all the skills. Holistic product development thinking is first of all a stance, but beneficial personal characteristics like being analytical and experienced with product development in a complex context will probably be very helpful.
Functional architecture is also a matter of facilitating communication regarding a need or problem to solve. There are many suggested techniques to simplify this. One of them is i.e. to write short cards* with a short formulation of the need/problem and related acceptance criteria (*metaphorically speaking if remote). This can serve as a foundation for the conversation between the customer (user) and the coders. — Writing the stuff down in a simple way, once discovered, and displaying the different items as a dynamic, prioritized list has turned out to be very effective.
While i.e. cards function as tangible, concrete artifacts, the work to discover what to write might be both time-consuming and often kind of a detective approach. Typical approaches include interviewing, digging for root causes, picking up subtle nuances from conversations and workshops as well as analyzing existing processes, technical eco-systems, user behavior patterns, and so on.
In the fast-paced and complex world that often is affecting digital product development, my experience is that functional architecture is a continuously ongoing work. -Normally involving more than just people with high skills doing functional architecture work.
That said, some years ago I was hired by a traditional legacy company with a specific mission to: identify- and formulate user-stories regarding a “fuzzy” vision of a new internal product intended to improve their effectiveness.
For this client, it was beneficial to explore the potential product development start-up by spending just enough time where just a few of us were pioneering in “the misty forest” of hidden needs before designing and creating a product team.
The pioneering work consisted of things like context- maps, stakeholder- maps, a clarified formulation of product vision, early thoughts regarding product boundary, user story mapping, an item list of needs/ problems to solve, and initial prioritization.
Sometimes the context for functional architecture work is leaning more toward the business perspectives and other times it`s leaning more over to the technical perspectives. No matter what, I think it`s about bridging and to some point being able to observe, understand & communicate between different perspectives and disciplines.
If you are interested in exploring how Computas can support your product development by the competency of functional architecture we are excited to meet you and together reflect more specifically regarding your situation.
The significance of functional architecture as a competency in digital product development was originally published in Compendium on Medium, where people are continuing the conversation by highlighting and responding to this story.