Enterprise Architecture Services
Process
As part of key focus on proposal preparation, we will help you define
the end state architecture. The end state
represents the target system for all migration steps defined in the
roadmap. This architecture will be adapted according to your business
objectives, and will define the necessary system components to close any
gaps identified during the business analysis period.
The enterprise architecture deliverable includes the high level model
defining the current and target architecture environments, and the
transitional processes for evolving from the current to the target in so
far as it is required for the proposal.
The following detailed steps are followed as part of Quilmach’s
architecture development methodology:
- Validation of business objectives and technology commitments
- Walk-through of existing process workflows and systems.
- Identification of existing hardware and software
- Validation of existing SLAs
- Identification of existing data bases and data propagation/maintenance flows
- Validation of technology and development plan
- Validation of end state requirements
Architecture Reference Model
A clothing designer who is competing on an episode of Project Runway designs according to the specific challenge needs by choosing the appropriate textiles, incorporating his or her own particular professional touches even when using pre-made patterns to construct the outfit. Architecture models are fundamentally no different. While solving a similar business problem, most architecture models will end up looking alike regardless of the vertical industry to which they apply. For instance, the architecture model for a high transaction airline reservation system is going to be very similar to the architecture model for a high transaction banking system. Indeed, these verticals do in fact share many of the same technologies. Still, you can’t just copy a model from a textbook and brand it as the definitive model for your company. Below is a sample ARM for a hospitality company providing reservation services:
At a minimum, the model must meet the following characteristics:
- It will be Realistic and Relevant. No matter how abstract a model, it should ultimately be implementable. A model that comprises quantum computers would not be realistic today. Also, the term “relevant” as applied here means that the model should relate to the specifics of your company.
- It must be Mutually Exclusive and Collectively Exhaustible. This is a fancy way of saying that it should be complete, but also economical, in its definition—without overlaps and without gaps. Unlike actual system implementation designs, which I believe should be slightly redundant and even overlapping for reliability and security purposes, reference models are there “for reference”; so they can, and indeed must, strive for Platonic perfection.
- It should serve as the primary communication mechanism. The model should describe the key areas as inter-related system modules that together serve clearly identified business functions core technology elements in a simple fashion.
The actual Architecture Model will probably be a brief reference document outlining in narrative form the key concepts of the model: components, key technologies, interaction maps, component inter-dependencies. However, its key element will be a visual representation of the end system via a highly iconic diagram that incorporates all the key elements of the logical architecture and its mapping to business processes. I call this diagram the Architecture Reference Model (ARM). If the ARM is to become your banner in all subsequent architecture socialization efforts, it should serve multiple purposes. Below is an example of an ARM for a typical hosip