Enterprise Architecture Part 2

Enterprise Architecture Part 2

We have previously addressed the concept of enterprise architecture. Now we probe into the fundamentals to be considered when defining the design phase of enterprise architecture. When developing an enterprise architecture, like solving any problem, the when’s, who’s, what’s, when’s, and why’s must be clarified. Considering pieces like data, functions, networks, people, the schedule and the motivation supporting the project will contribute to the success of implementation. It is important to understand how each project in the organisation ties back to high-level corporate goals.

The following are the Enterprise architecture domains:

  • Business architecture

This bridges the enterprise business model with the enterprise strategy. It speaks to the functional structure which is the business services and business information. At this stage, functions are identified and resources are reserved. This will define the business capability and how the business goals will be achieved. It is a prerequisite to be able to perform work in any of the other enterprise architecture domains.

  • Application architecture

The application architecture ensures that the collection of applications being used by an organisation to create the composite architecture is scalable, reliable, available and manageable. It is used to identify, define and manage the interactions between business applications. Breaking this down will classify any technological risks that may impact future business.

The service model defines who the customers are, what services the organisation provides and what channels are used to provide the services. The process model defines the processes, the value chain, work packages and the involved tasks.

  • Technical architecture

This is the design and documentation of a software application. It supports the application architecture by defining the communication networks, security, hardware and software. It assesses the compatibility of new systems with already existing company devices and equipment. Information regarding this layer is normally provided by the database administrators, programmers, security officers and other roles that deal with the networks, security, and hardware and software management within the organisation.

  • Security architecture

The security architecture looks at the requirements and provisions that must be addressed within the organisation. From this plan, the definition of where security controls must be applied, what they are and why the security measures are in place is specified. The effects and odds against critical business assets are identified in this area.

The identified measures will facilitate business risk exposure objectives and the mitigation plans for materialised vulnerabilities. Not only does the security architecture assist in terms of risk management, it puts the organisation at an advantage with legal and regulatory compliance.

  • Data architecture

This is an elaborate description of the governance of the company’s data around aligning the IT programs and information assets with the business strategy. The attribute structure and physical class of system interfaces manages the way in which the data during the implementation of new systems changes when moved amongst systems. It also defines the collection of data in terms of how it is stored, used, arranged and how it is put to use in the database systems. This ensures that integration, quality, availability, integrity and confidentiality are maintained

“In technology, change is too fast for even the best reaction time to be fast enough. These days, thriving is not only about agility; it’s also about anticipation”

The solutions that IT customers are looking for are increased effectiveness to reduce costs and increased customer experience to boost revenue. The enterprise architecture is one of the many resolutions that IT and business are bringing to the corporate world in order to add value and manage business continuity. A well-defined IT strategy is the difference between being an implementer vs being a driver of business.