Postcards from the Revolution

Wednesday, March 06, 2002

Posted by Mike Tarrani 6:41 AM
Zachman Framework - Part 2. My last entry introduced the Zachman Framework and background information. This entry is going to be brief because there are two people with whom I want to collaborate before I get too deep into this topic. The first is Muthukumar U, a close friend who works as a risk management specialist at HSBC Bank Middle East in Sharjah, UAE. Muthukumar is much more than a risk management specialist - he's a deep thinker and genuine intellectual who is well versed in a number of subjects. Among his many talents is an abiding passion for knowledge management. Because the Zachman Framework is an ideal structure for developing architectures and solutions that enable knowledge management I want Muthukumar's thoughts before getting too deep into that aspect of the framework.
I also want the benefit of Kate Hartshorn's knowledge and experience. Kate has a keen understanding of knowledge management, in addition to data mining, information transformation and related topics, all of which are enabled or fostered by the Zachman Framework.
Knowledge. Although I am waiting to discuss aspects of knowledge management with Muthukumar and Kate, I do have my own ideas about aspects of the subject. Two areas in which I have professional interests are business case development and value analysis. The 20-page whitepaper (in PDF format) titled, Estimating Benefits of Knowledge Management Initiatives is an important discussion of the methods and tools used to prove the business value of knowledge management. This is especially important if you're examining the potential use of portals as a means of disseminating knowledge throughout the enterprise.
If you need to quickly get up-to-speed in portals as a technology and as a business strategy I recommend Heidi Collins' Corporate Portals: Revolutionizing Information Access to Increase Productivity and Drive the Bottom Line. I reviewed this book on Amazon on 8 April 2001. Linda also wrote an Amazon review on 24 February 2001. Ms. Collins has a new book that will be out in May titled, Enterprise Knowledge Portals: Next Generation Portal Solutions for Dynamic Information Access, Better Decision Making and Maximum Results. Since I was pleased with her first book I pre-ordered a copy of this one.
As you delve into the Zachman Framework you're going to notice that XML is a recurring topic. Discussing the many reasons for this is well beyond the scope of this entry; however, the short version is XML's ability to facilitate data exchange among disparate systems and data sources makes it an ideal technology to employ in any enterprise architecture. Extracting the data is typically done with SQL queries. XML DTDs are the templates into which the results of the SQL queries are stored, which allows you to aggregate data in ways that were not easy before XML came along. Details and techniques are provided in XML and SQL: Developing Web Applications by Daniel Appelquist.
XML and portals are also usually associated with each other. How specifically they are associated can be discerned by reading Building Corporate Portals with XML by Clive Finkelstein, Peter G. Aiken and John A. Zachman (the man himself), or my favorite book titled, Metadata Solutions: Using Metamodels, Repositories, XML, and Enterprise Portals to Generate Information on Demand, which I reviewed on 22 September 2001.
Are you starting to see a pattern? It's all about the data. It always has been.
Yellow Light. We have the standards, techniques and tools to bring to bear on initiatives and strategies that not so long ago would have required us to do a lot of inventing. Here's an example requirement that can be easily met using some of the standards and techniques I've just discussed:
Requirement: Realtime updating of customer account information and transactions to a central server. Customers should have access to Internet banking functions, including fund transfers, payments, status lookups, etc.
Situational Analysis: Current account and transaction data resides at the branch level, and is managed by different systems depending on the branch.
Constraints:
Cost - an enterprise solution is planned with a two-year planning horizon and business goals dictate that no large investment be made in infrastructure that could be obsoleted by the enterprise solution
Competitive pressures - the bank wants to achieve competitive advantage now using an interim solution that will capture and/or retain customers who want Internet banking
Existing infrastructure - 290 branches are interconnected with varying connectivity options, most of which are relatively low speed (VSAT, ISDN, etc.); the solution cannot require a change to the existing infrastructure.
How to proceed? A solution that can meet stated requirements within the constraints can be achieved as follows:
Task: Analyze the data structure used in each of the existing systems. Deliverable: E-R diagrams and data dictionary for each system.
Task: Develop a master data dictionary using agreed upon data naming conventions. Deliverable: Master data dictionary.
Task: Develop a master DTD using data naming conventions. Deliverable: Document Type Definition master template
Task: Develop SQL queries for each data source. Deliverable: Tested SQL queries for each data source.
Task: Develop and configure central portal to accept customer sessions, assure identity, issue transaction requests and display results. Deliverable: Design specifications, access controls, secure transmission protocol(s), user interface, application and presentation layer coding.
Of course, the solution I just presented is something I quickly pulled out of thin air, and many details have been glossed over. The point is that using the alphabet soup of SQL, XML, LDAP and other standards and technologies a solution can be crafted.
The Rub. Therein lies the rub - the solution shortly becomes an impediment to the planned system, which is two years out. It (or a more fleshed-out version) may address the immediate requirements and stay within the constraints, but it is short-sighted. The missing ingredient is a larger view of the problem, and that view should be based on a framework that serves as a blueprint for the evolving architecture. This is where the Zachman Framework's value becomes apparent. The viewpoints and focus that I discussed in my last entry not only add structure to the solution, but place it in context of the much larger domains of business strategy and enterprise architecture.
Wrap-up. I am out of time on this entry. The foregoing will [I hope] spark ideas, and the following will provide more details about the Zachman Framework and related topics:
Two articles about enterprise-wide architectures, with a focus on the Zachman Framework
Eight MS Word documents covering topics ranging from enterprise requirements to enterprise architecture engineering, all of which directly reference the Zachman Framework
PowerPoint presentation on the Open Architecture Group Framework
MS Word and PowerPoint documents about architectures and modeling, with an emphasis on the Zachman Framework
A collection of PowerPoint presentations on miscellaneous topics about or related to the Zachman Framework
Integration topics, including integrating the Zachman Framework and Rational Unified Process (see my Notes from the Field entry from earlier today)
Data issues, consisting of two MS Word documents: Data element naming standards and data standards for patient medical records
End Note. I hope to introduce business rules in my next entry, and if I have an opportunity to discuss knowledge management with either Kate Hartshorn or Muthukumar U I'll summarize key findings from the discussions.