Frameworks
| Kello received a call from Kathy Budhooram, director of the Data Center, who wanted his buy, in for a new database infrastructure and systems management framework and wanted to write a check for $55 million. Kello asked about the approach Kathy used to reach her decision on product selection. Kello also asked whether anyone from Kathy's staff performed trade-off analysis on alternative approaches and how it compared with other solutions in the industry. Kathy admitted that she did not compare the recommended solution to anything else but highly admired the vendor's presentation and marketing materials. Kello then asked whether she talked with any of the database and/or network administrators who would have ultimate responsibility for the solution. Sadly this had not occurred. While multiple objectives are behind building a data architecture (Figure 11-2), the main reason is to maintain an infrastructure that allows for the support of new business processes at the enterprise level in an easy manner. The organization should follow a framework for building a data architecture. Kello realizes that good data architecture will allow his organization to maintain the appropriate balance between business innovation and IT, and thus realize cost savings. Figure 11-2. Layered data architecture.
Let's look at the main components of a data architecture framework. Business ArchitectureBusiness architecture (conceptual architecture) identifies processes at the enterprise level and outlines the desired outcome the business seeks, as well as the steps necessary to accomplish it. In a vast majority of organizations, it will be relatively easy to find documentation on the solutions that have been implemented to date. One may find at this step that many of the business processes are out-of-date and/or no longer provide any business value and were done solely for historic reasons. It is best to eliminate any business processes that do not provide business value at this step, as they should not occupy resources.
Business Object ModelingIdentifying business objects and the data that need to be associated, classifying business objects and their relationships to each other allows the architect to develop classification schemes that are necessary for creating metadata. In this step, it is a good idea to assign a unique identifier to each object, as well as to capture a description of the business processes the business object fulfills. One should also consider attaching a representative sample of the data, as well as attaching a statement for the original motivation behind collecting this piece of data. At this stage, one should make sure that processes and their associated data are consistently named throughout the enterprise. In all but the smallest organizations, it will be difficult to find the same process referred to with two different names. Usually this occurs across different business units. Inconsistencies in processes and their associated data may include assigning different labels to refer to the same type of process/data, associate the same label with different types of process/data, representing the same process/data using different formats, and so on. Eliminating these types of inconsistencies will remove hurdles now and in the future when integrating disparate business systems. It is important that one not get hung up on getting it perfect at this step. Identifying the major business units within the enterprise and the relationships among them should be considered thoroughly at this stage. One will find that the identified business processes within each business unit should ideally map to the identified business objects. Business DataBy capturing business data used in a business process, an organization can assess the effectiveness of a given business process. Additionally, identifying the data that are needed to achieve the desired outcome helps an organization know what data to keep as well as what data to discard. It is important to identify how data are handled within various business processes. The data that are used by the process and used by other common processes, as well as those that are communicated externally, should be documented. By classifying data in this manner, it will become evident that certain transactions exist and must be supported by any new business processes (See Figure 11-3). Figure 11-3. Architectural process.
At this stage, an architect should be on the lookout for data integrity and for potential breaks in data integrity. Enough information has been collected to find spots where decision support systems have holes in the data they truly require to be complete. Sometimes, this may be due to vocabulary not caught at the previous stage. For example, within Canaxia's business process, the company uses the word name as both a noun and verb, where name can refer to a person (e.g., Fong Sai Yuk) or a promotion initiative (e.g., finding the next CTO). One may also discover that the formats vary for the same data used by different business units. For example, date of manufacture is displayed by U.S. subsidiaries as 09/10/2001, when sold to the U.S. military as 09-OCT-2001, and by Caribbean subsidiaries as 10/09/2001. Other business units, such as manufacturing, may also append the time the unit rolled off the assembly line and could display local time or Greenwich Mean Time. This type of information is usually discovered only in discussion with participants from all parts of the organization, not from just a selected area. The solution to this conundrum is the ability to have multiple views into the data. This is discussed in detail in Chapter 7, Agile Architecture.
Alternatively, for those who eschew waterfall approaches, you may prefer to see the diagram drawn as in Figure 11-4. Figure 11-4. Architectural process the agile view.
ArchitectureAt this stage, we have gathered all required information needed to construct a model for our data architecture. This model will reflect how Canaxia conducts business. Our framework suggests that we incorporate existing relationships and model them so that new systems and significant upgrades will support any proposed system's new processes and standards. Validation/Final ReviewBefore any architecture is declared ready for production, it is important to consider what may have been forgotten. At this stage, it is important that the architecture support all the requirements the business needs to process information. This can be done by conducting a data gap analysis. Any concerns expressed by key stakeholders should be completely addressed here. Following are other gaps that should be identified:
The review should also consider qualitative criteria (e.g., security, performance availability, accuracy, costs, volumes, and so on) and provide criteria that are as measurable as possible. Following are some common items to measure:
The goal at this step is to guide the data architecture efforts toward the qualities required in the processes that manage the data. This could also be extended to the applications that the organization builds or purchases, as well as the underlying technology infrastructure. Many heavyweight frameworks for data architecture are available commercially and will be more impressive to the management team (at least those who are not aware of agile methods), cost an organization significantly more in the way of time and resources, and not produce the desired return on investment. We propose a lighter-weight approach that will result in better success. Using the framework we have suggested allows an enterprise to increase its data integrity through consistent implementation of business processes. This stage would be a good time to conduct a review with the goal of early detection of any mistakes made during the process.
|
EAN: 2147483647
Pages: 148