EA in transition: Guide to keeping up with disruptive technologies
A comprehensive collection of articles, videos and more, hand-picked by our editors
Functional and process design is part of an enterprise architecture (EA) methodology, the key bottom layer where alignment with actual IT elements is created -- or not created. One of the greatest challenges enterprise architects face is that critical elements of an EA model are often documented, rather than designed, in their initial project work. This occurs because most EA is applied first to an organization where IT and business...
process relationships are already established.
Setting the stage for success
Many enterprise architects find that when technology or business changes require revisions to the functional and process design scope, they have neither the organizational nor technology support needed to influence optimum business-IT alignment. To prevent this, they must lay the groundwork for scope-changing projects, insure they have the best modeling tools, and create effective transfer of project control to systems architects at the appropriate point.
For an enterprise architect to successfully drive changes in functional and process design scope, it's essential the current EA model is an accurate representation of business-to-technology mapping. In most cases, the fastest way to accomplish this is to start with the business-process level of the architecture and validate the gross business workflows found there. These serve as the input to functional design, so errors at the business-process level will defeat future alignment. Business processes also frame business process execution language development and testing, which is the first level where technology and business processes have to be congruent.
Solidifying the enterprise architect's design influence
At the same time the review is underway, a smart enterprise architect will coordinate with the business line management in each business process that's likely to be impacted by the project. Since architects typically do not have supervisor authority either upward into the line departments or downward into IT, they need to establish a good relationship with both adjacent areas' leadership personnel. Start with the business process side because business goals are the baseline for alignment activities.
A smart enterprise architect will coordinate with the business line management in each business process.
The second point in solidifying an enterprise architect's influence on functional and process design is to model both activities in a way that can be communicated bidirectionally. Unified Modeling Language, popularly used by IT professionals, is generally disliked by line business planners and managers because of readability.
Business Process Modeling Notation is probably a good example of a model that's simple enough to be understood by business management, but sophisticated enough to convey business process and functional detail. The IDEF (Integrated DEFinition) tools were developed by the Defense Department and are available as open source. The collection offers appropriate tools for every level of modeling. Support and documentation may be a bit thin, so be prepared for a learning (and teaching) curve.
Selecting the best approach
Enterprise architects will debate the best approach to functional and process design, particularly where stimulus for change is from the technology side. This is the area where architects historically have the most difficult job. Methodologies for EA are inherently business-driven and therefore align technology choices to business practices.
When a revolutionary (or even just significantly improved) technology becomes available, these methodologies are often ill-suited to create optimum linkage. The enterprise architect will have to reverse-engineer or track the EA model backward from the low-level process design up to the functional and business process levels.
Process modeling can be altered to reflect the optimum use of new technology, and this can be done with the goal of minimizing the impact on the functional layer. If that's done, technology changes would rarely rise to the point where they'd have a significant impact on business processes, and thus, the impact on operations would be reduced. Often, though, a truly significant technology shift will force higher-level accommodation to the technology to secure maximum benefits. At this point, another approach may be indicated.
That approach is goal modification to support technical practices. Typically it's considered a violation of EA practices to presume a technical goal at the business process level, but experience shows that incorporating revolutionary changes may involve recasting practices to presume a technical outcome. To do this:
- Start at the business process level and presume that a business goal is to operate using the new technology.
- Frame the business processes and dissect them into functional and process designs in the normal way.
Since the new technology was a high-level goal, it's going to align with the process design output.
One of the major benefits of this approach is that it secures business alignment for new technology in the normal way, meaning that translating project control from EA to service assurance is likely routine. Enterprise architects, by assuring business alignment, can insure an optimum business case can be made for the investment.
There is still a risk, however, that the technology shift will either lose touch with critical business practices as implementation progresses, or that implementation will demonstrate a need for accommodation. Unless there's evidence of a gross error in alignment, the best approach here is to follow the reverse-engineering path. This can be done by making changes in process design to align with implementation needs, then tracking the impact to business processes to map the changes in implementation to possible changes in the business case.
Cloud computing, mobile worker empowerment, and other technical developments can create profound changes in technical resources. Enterprise architects should remember it's rare for high-level business process design not to be anchored, to a degree at least, in current technical options. It's not a bad thing to acknowledge that relationship, and harness it explicitly to ensure that new technology options are well supported by a business case. That's how architects fulfill their supervisory role of guiding investment in IT.
About the author
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.