The concept of business architecture and the role of the Business Architect did not exist when most people today entered their respective industries; no curriculum was available to prepare anyone for the role and, as far as I know, there is still no certification available for today’s Business Architects. So from a practical sense, what does one look for when hiring a Business Architect or promoting someone to the role of Business Architect?
What is Business Architecture?
Before describing what to look for in a Business Architect, I would like to ensure that we are working from the same definition. Though I have seen various definitions of business architecture, I do not intend to debate them here. Rather, I turn to the OMG for a working definition for the purposes of this article.
The OMG Business Architecture Working Group defines business architecture as “A blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands.” Their overview of business architecture states, among other things, that “Business Architecture defines the structure of the enterprise in terms of its governance structure, business processes, and business information. In defining the structure of the enterprise, business architecture considers customers, finances, and the ever-changing market to align strategic goals and objectives with decisions regarding products and services; partners and suppliers; organization; capabilities; and key initiatives.”
That is quite a mouthful.
Breadth of knowledge
It is clear that the Business Architect must have a broad, enterprise-wide view of the business. The Business Architect must have varying degrees of appreciation for strategy, processes and capabilities, enabling technologies, and governance. I say “varying degrees” because I do not expect any one person to be an expert in all of these areas. However, for which ever area(s) the Business Architect is an expert, he or she must at the very least be knowledgeable in the other areas and able to leverage the skills of those experts. I also believe that the knowledge that the Business Architect possesses must be practical knowledge, not theoretical. Theoretical knowledge is helpful. However, the Business Architect will have considerably less credibility with experts in other areas if he or she has never had any hands-on experience in those areas.
The role of the Business Architect
Why, one might ask, does the Business Architect need credibility in every area when there are experts in each of those areas? The answer to that question lies in the Business Architect’s role.
The Business Architect is the liaison between the business and IT: when the Data Architect “speaks data” the Business Architect must speak data; when the business talks about its information needs, the Business Architect must “speak information.” The Business Architect must know enough about the information needs of the business to covey them to IT and enough about data constraints to translate them into something the business can understand. The same holds true for business strategy and IT strategy, business processes and work flow automation, business initiatives and IT initiatives, and benefit realization and service delivery.
Conclusion
When looking for someone to fill the role of the Business Architect, look for someone with a long history in technology and an equally long history focused on the business.
An indicator of a long run in technology, other than a resume, is someone who has successfully worked through every phase of the software development life cycle on multiple platforms. This is not a short process. It takes time to become proficient as a developer, move into application design, and eventually take on the role of Systems Analyst. If this transition involves multiple platforms, this individual will have been involved with multiple technologies and potentially multiple data bases and gives this individual breadth of knowledge. If the person has ever held the title of Application Architect or Data Architect it would suggest a depth of knowledge that goes beyond development. Achieving these titles is no easy task. They demonstrate an eye for the big picture and the ability to apply architectural principles to a solution.
Both of these examples represent practical knowledge. Certificates are nice but while some certificate programs include the practical application of what was taught, others may only present theoretical knowledge intended to prepare the individual for practical experience. Be sure to ascertain the degree to which the individual followed through to gain that practical experience.
You may be presented with someone that has held the title of Business Analyst. However, the title of Business Analyst is not necessarily indicative of a focus on the business. All too often, Systems Analysts are given this title of Business Analyst simply because it is their job to elicit requirements from users; however, they are still systems analysts. A title like Process Analyst, on the other hand, indicates that the intended focus is on a business process and not on a system. Keep in mind, this does not indicate that the person did a very good job of focusing on the business but at least the intent was to have that person focus on the business. If that person then progresses through roles like Process Engineer, Process Architect, and Senior Process Architect there is a good chance that that person did, and still does, do a good job at focusing on the business.
Finally, look for someone that has good management and leadership skills – and, yes, there is a difference. This person should not only be able to tell you the difference between management and leadership but should also have demonstrated proficiency at both.
