GCDOCS Architecture – All for One and One For All!
Change management best practice teaches us that lack of awareness is the primary source of resistance to organizational change. It seems like architects working on EDRMS or GCDOCS have to face this problem redoubled: first, they have to make their stakeholders aware of what they are attempting to design. But at a more fundamental level, they also need to confront the fact that information management itself is very often unaware of the scope of what it is asking of the organization. And it’s a big ask.
Designing for X, Y, and Z
“All for one, one for all–that is our motto, is it not?”
“And yet–” said Porthos.
“Hold out your hand and swear!” cried Athos and Aramis at once.
Alexandre Dumas, The Three Musketeers.
One of the most difficult questions for an EDRMS or GCDOCS architect to answer is “for whom am I designing?” Unlike a Web IA, we can’t square-in on end-users; nor, like a records architect, are we primarily bound by best practice, policy and legislative requirements. While our limitations are set by the technical architect, we cannot design solely to her needs either.
Very often, we settle for a “mixed” approach; we are designing a GCDOCS implementation for business AND to meet policy and legislative requirements in a way that suits IT limitations. We seek to incorporate IM/RM best practices AND meet the usability requirements of end-users. We define all our stakeholders, and then aim to design for all of them simultaneously while still being technically feasible; we want to have our cake and eat it too.
But how do we defend our decisions when the situation is not so balanced (and it rarely is)? How do we apologize for choosing one side over the other, as we very often must do? How do we prevent ourselves from designing what are in effect several (often conflicting) “mini-GCDOCS architectures” stitched together, and instead focus on the big vision?
The struggle between the need for a single way of doing things and the many different ways things “get done” in the wild often brings different groups to loggerheads, and when we compromise, not everybody can discern an immediate advantage for themselves.
How do we justify causing such a ruckus? In the language of change management, our promotion of external “awareness” needs to be supplemented by a strong “self-awareness”. Our defense needs to be as big as our architectural goals are transformative.
We are building an IA to move the sum of the organization forward, not just its components
With an EDRMS or GDOCS architecture, we often pretend like we are building something small that will just “fit around” the business, RM, and IT. We have to recognize that the change we are proposing is big, affects everybody, and is, in the end, proposing to create a brand-new entity out of an old organization. If a GCDOCS architecture is to be done effectively, it needs to be massive, and everybody needs to be onboard. This means that change management comes first, and particularly, a focus on the “awareness” of our scope.
The IM end-goal is a collective vision
The implementation of any EDRMS or GCDOCS architecture at the Enterprise Level entails standardized activity and culture change throughout an organization, from top to bottom. It must break down silos and create a single direction for the organization. A combination of directive, discipline, and policy, the purpose of a GCDOCS architecture directly affects the behavior and capacity of an organization from its very roots; because it centers on the creation of a set of standard behaviors and structures with an Enterprise-wide degree of participation, GCDOCS architecture results in a really “collective” way of working.
We are not designing for users, business, or RM, but for the benefit of all
This ultimately means we are not designing, in an accruable fashion, “for you AND you AND you”; we are designing for “all of us” all together.
And this means confronting compromise. As EDRM/GCDOCS architects we need to desist from pretending like we are directly designing for each segment or client group individually. We cannot claim to be able to be entirely dedicated to usability, while at the same time completely in accordance with our IM/RM policies and standards. We need to ensure that our vision and strategy defines the kind of IM-ingrained organization we are trying to create, and accept that this is not simply tacking on IM to already established functions. We are trying to do something new, and something positive. This cannot be “behind the scenes” in every case.
“What’s in it for me” becomes “what’s in it for us” – a culture change through architecture
Oftentimes the enforcement of an EDRMS or GCDOCS architecture triggers a conversation around the question of standardization. The struggle to get everybody on the same page while at the same time respecting their very real and distinct business needs can get very heated. No matter how much is conceded or withheld from a client, the question of “what’s in it for me” necessarily moves towards “what’s in it for us”. In many cases for the first time, business units are forced to consider advantages that reach out beyond their siloed needs and that speak to the organization as a whole.
If awareness of the scope of our ambitions are on the table, it will make the process much more productive. While it may take many carrots and sticks, negotiations and deal-brokering to ultimately reach a compromise, by making use of the ideology of collectivity up-front and consistently, we are practicing ourselves the change we want to impose.
When an organization truly commits to managing its information and implementing an architecture in GCDOCS or an EDRMS, it is committing to more than just cautionary house-keeping, or the occasional “awareness” program, or a check-list of best practices; it is taking the collective view of its own work and its own mission – whether it realizes it or not.