On occasion, the inmates actually do take over the asylum. Similarly, business personnel can be defeated by their IT peers, although many might argue that such an unexpected role reversal cannot happen.
They say that business is in charge, that business has the budget, and business dictates requirements. They are wrong; business is supposed But circumstances do happen wherein IT influences business to such an extent that IT becomes the puppet master. When such a defeat of the user kingdom occurs, the evidence is visible in users who can only explain the business in terms of the specific IT implementation, or lack thereof. And under these extreme IT controlling influences, business may often see the existing implementation of a solution as “the only way.”
Terms like “GUID” or other system-generated bits and keys enter the business discussion as if they were a natural part of the trade. These users have been over-exposed to raw implementation details and choices. Once this vicious cycle takes hold, unusual things appear; the latest solutions or iterations often include the same short-comings as the old solutions. What is most recent is only newer, and not very much better. Ultimately, IT staff become the only ones who can explain the improvements, which may be limited to the coding language or tool used behind the scenes.
As the description of the business now incorporates these IT additions, any new solution analysis is made that much harder. For an outside analyst entering the flip-flopped world, identifying requirements is a Himalayan challenge. Internal analysis becomes a non-entity, since “everyone knows” that what is present is “as it is” and “as it is” is just fine; in fact, how could it possibly be any different. But for an outsider, alien to the existing status quo, separating out true business rules and requirements from the accepted implementations and code-based cul-de-sacs is a very difficult task. The user has been trained to explain only the actual implementation and not what business task it was intended to address.
It can be a verbal battle to help users climb out of the box they have become accustomed to living within. The analyst must continually push the users to embrace the heart of the desired functionality, to split apart terms and ideas that these users have accepted as inseparable. The same question must be asked yet again but from different aspects and perspectives to see what things truly stand for functional concepts and what things stand in the way. There is a certain joy an analyst or designer may experience in bringing a user to the precipice of understanding where the user can start thinking in terms of ideas, rather than of column names. The accepted IT-named identifier may turn out to be a strong key given to a weak associative entity, and no one in business may really understand why the association exists. A good analyst strips the varnish off these concepts so these basic ideas can be explored and refined further. Some ideas may need to be removed from future designs because these ideas represent artifacts of a specific approach rather than a true requirement. Ideas that remain should have agreed upon business definitions that make the object/identifier’s reason for existence clear, to both business and future IT maintenance staff.
A good data architect must also be a very good business analyst. When applying those business analyst skills, the data architect must work hard to develop the ability to describe the business in business terms, relate to the business community, and that community’s issues, concerns, and hopes. The data architect serves as a bridge from business into the technical community. Implementation possibilities are truly infinite. Data architects skilled in their craft can identify the options that help achieve the business goals, versus those alternatives that stifle the business goals. And, ideally, data architects do not force business to become technical, or pseudo-technical, and most certainly they do not try to convince the organization that only one possible solution exists for a problem.