by Nicolaas Botes –
Planning an add-on or upgrade to your organization’s enterprise software capabilities? You’re certainly not alone. Many organizations at this moment are about to take that step.
It’s a common occurrence. As organizations grow and evolve, it’s inevitable that they encounter the need to expand and enhance the capabilities of their enterprise software. So if your organization is at that point, you share a common need with many other organizations.
And if you’re not careful, you’ll share one other thing with many organizations. You’ll make a critical mistake in the process that will leave you with software that simply doesn’t perform as needed — best case scenario. Or, worst case scenario, you’ll have a system that’s perpetually on the verge of total collapse, like a house of cards.
That critical mistake? The failure to put your project in the hands of an enterprise architect.
You Wouldn’t Make This Mistake…
Let’s consider an analogy. Let’s imagine that your company is about to build a new office complex instead of a software system.
How would you go about doing that? You’d hire credentialed construction professionals with the specialized training and experience to complete your project successfully.
And your very first hire would be the project architect. Your architect would then develop a blueprint that would guide all of the specialized tradespeople in the completion of their particular roles.
Construction crews, plumbers, electricians, mechanical engineers, interior designers — all would be able to follow the guidance of the architect, via the blueprint, in the successful completion of their jobs. All would be able to perform their individual tasks in symphonic harmony.
Each role within the project would be crucial. But it would be the architect that provided the guidance that ultimately ensured the successful completion of the project.
And that’s why you certainly wouldn’t make the mistake of placing your construction project in the hands of people that lacked the appropriate expertise.
…But You Might Make THIS Mistake
Now let’s return to your soon-to-be-launched enterprise software project. What approach will you take with the project? Unfortunately, you’re likely to make a critical mistake that many organizations make: the failure to use an enterprise architect.
Instead, many organizations rely upon ill-skilled people to guide the project. Or they might bring in a specialized architect based upon assumptions about the direction of the project; a cloud architect, for example. But these people simply don’t possess the big-picture expertise required for planning and guiding the project.
And there’s a complicating factor: Most enterprise systems already consist of a cobbled-together collection of individual systems, evolved over many years, that just-barely work together. In my experience, that’s the way it is at virtually every company.
Making additions to these systems must be done very carefully, and with precise planning that incorporates a big-picture understanding of the current state of the system. It’s also important to conceptualize future requirements for the system, developing the future-state architecture along with a roadmap for transitioning from current state to future state. And all of that requires an enterprise architect.
But, perhaps most importantly, the enterprise architect will ensure that everyone participating in the project will understand what they need to do to make the project successful.
Speaking a Common Language
In the analogy of the office construction project, the architect provides guidance in a common language: the blueprint. Everyone involved in the project will speak the language of the blueprint. The electrician will understand the symbol that indicates an electrical outlet; the construction engineer will understand the designation of a load-bearing interior wall; and so on.
An enterprise architect will similarly ensure that everyone involved will be “speaking” a common language. And that will begin with choosing the most appropriate language for the project. Those different languages are called frameworks, and some of the most common include:
- The Zachman Framework: A fundamental enterprise architecture structure that helps reduce the what, how, where, who, when, and why variety of abstractions
- The Open Architecture Framework (TOGAF): A comprehensive and generic framework that splits enterprise architecture into four categories:
- Business architecture
- Information architecture
- Application architecture
- Infrastructure architecture
- The Federal Enterprise Architecture Framework: Promotes a shared development that is durable for developing and documenting architecture descriptions for U.S. federal processes shared among federal agencies and other government entities
- The Treasury Enterprise Architecture Framework: Provides guidance on the of information systems architecture for treasury bureaus
- The Department of Defense Architecture Framework: A comprehensive framework and conceptual model that enables the development of architecture for the Department of Defense (DOD) systems
The enterprise architect will have the expertise necessary to select the best framework for the project. Or, even better, the enterprise architect may be able to deploy a hybrid framework that best fits the needs of the project.
An RCG enterprise architect, for example, will likely deploy RCG’s proprietary framework, the RCG|enable® EA Framework. The RCG framework is, essentially, a scaled-down version that cherry-picks some of the best features from the Zachman and TOGAF frameworks in creating a methodology that will be effective for most any project in any organization. (For diagramming notation, RCG utilizes a combination of BPMN and ArchiMate for rendering enterprise architecture diagrams.)
A Very Common — and Costly — Mistake
As noted above, the failure to utilize the expertise of an enterprise architect is a common mistake.
Why do so many organizations make this mistake?
I believe it’s simply a lack of understanding about the importance of enterprise architecture. Many in the world of information technology just don’t equate the necessity of an enterprise architect with that of a building architect. And yet, foregoing the services of each respective type of architect can result in similarly devastating consequences.
After all, it doesn’t take much of an ill wind to send a house of cards — whether a physical building or an enterprise software system — tumbling to the ground.