How to Bridge the Business & IT/Network Divide?

Posted by cfaurer on March 31st, 2014 filed in Frameworx Consulting

AMKBCloud-TOGAF-FxWhat does The Open Group Architectural Framework (TOGAF) tell us about the Business versus IT/Network? Well, there’s a way to build a bridge between what the business wants/needs and what IT/Network has or can deliver – bridge the Business & IT/Network divide. That bridge is provided by Business Services, which tie together many of the key architectural constructs representing the business, information/data, application and technology architectures.

In the TOGAF metamodel the business is represented by process, which manages workflow to coordinate the manual tasks performed by an actor (party) in a role. The process also orchestrates the business services, which provide access to the applications performing the automated tasks. The actor belongs to an organization unit, which provides a means to manage enterprise employees and staff. There are additional motivational constructs as well as quality controls to set the direction for the organization and then ensure that the goals are being achieved as specified.

Below the business service are the information/data, application and technology architectures, which realize the specified service automation requirements. The realization can be as an API implemented using, for example, REST, Java, WSDL/XSD and/or CORBA technologies.

TOGAF provides a valuable architecture for understanding the key considerations of the enterprise with respect to providing people with the IT/Network capabilities they need to get their job done. But, TOGAF doesn’t offer industry specific architectural content that can be used to build an understanding of an enterprise. For that you must look elsewhere.

A good place to look for the Information, Communication, Technology & Media industry is the TM Forum Frameworx suite of best practices and standards that provide a blueprint for effective, efficient business operations for communication service providers. In using the Frameworx global industry standard language it becomes possible to consistently define and document your business architecture (using the Business Process Framework, aka eTOM), information architecture (using the Information Framework, aka SID), application architecture (using the Application Framework, aka TAM and Business Services and APIs from the Integration Framework).

The bridging architectural element that ties together the Business and IT/Network is the Business Service. Which is realized in most enterprises as implemented SOA services and/or APIs. SOA service and/or API artifacts are tangible and living representations of how the business task automation requirements have been implemented by development. Quite often, the development implementation of the business service is coded in a language other than that available from Frameworx.

What if the Business Service was specified using the common language of Frameworx and was the source for generating the requisite SOA service and or API realization?

Well, then there would be a bridge uniting the Business and IT/Network represented in the living artifact of the Business Service and its realized Frameworx-based SOA service and/or API. This can be achieved using a top-down and or bottom-up approach to Business Service specification and become an ongoing part of the software development lifecycle in combination with appropriate levels of governance to manage and maintain the enterprise architecture artifacts.

Leave a Comment

You must be logged in to post a comment.