Application Platform Strategies Blog

Joe B. on Data Principles

Blogger: Chris Haddad

 

Burton Group is fortunate to have Joe Bugajski on board as a Senior Analyst covering Data Access Strategies. Joe is a seasoned data architecture veteran who recently was vice president of Global Standards and Interoperability at Visa. Reporting to Visa’s Global CTO, Joe was responsible for worldwide interoperability of VisaNet data and applications and global service standards for transactions processing and payment data management. 

For his first Burton Group research report, Joe is writing about .NET 3.5 Support for Data Services: LINQ and ADO.NET. To put Microsoft's data technologies in context, Joe has created a data principle evaluation framework. The framework reviews capabilities in the following areas:

• Data Assets: Increase their value
• Enterprise Architecture: Support technology standards, goals, and plans
• Software Development: Promote code quality, reliability, simplicity, and security
• Development Management: Meet business objectives

While explaining the data principles framework would require an entire research report (hopefully one Joe will write soon), I have distilled out key evaluation criteria for this blog entry:

Data Assets: Increase their value

• Assure fidelity of data typing

• Preserve (business) semantics

• Understand reliability of data semantics

• Understand the quality of the data

• Map business semantics to actual semantics

• Minimize data movement

• Understand stored form of data and query logic

• Define information preserving data format conversions

• Calculate data access volumes

• Measure instantaneous rate of change of data values

• Measure total cycle time from access to persistence

• Understand persistence needed for disaster recovery

• Meet information steward’s requirements for data access

• Maintain principle of least access

• Secure private and sensitive data during access and use

EnterpriseArchitecture: Support technology standards, goals and plans

• Minimize code and architectural complexity

• Minimize total number of suppliers and contracts

• Minimize total number of active data formats

• Promote enterprise architecture plans

• Support multi-tier maintenance services

• Achieve compliance with internal technical standards

• Maintain semantic interoperability

• Preserve and enhance value of metadata stores

• Provide for data usage traceability and auditability

• Support nonfunctional requirements; e.g. security architecture

• Maximize continuity of architectural styles

• Maximize code and services reuse

• Maximize use of existing data stores

Software Development: Promote code quality, reliability, simplicity and security

• Minimize costs and time required to deliver code

• Minimize language complexity

• Minimize code complexity

• Minimize context switching (time lost in obscurities)

• Minimize coding errors

• Achieve closest match to functional requirements

• Meet nonfunctional requirements

• Promote code portability

• Promote reliable code walk-through

• Support frequent builds

• Support regression testing

• Optimize use of working prototypes

• Maximize unit testing

• Maximize code quality

• Maximize code readability

• Maximize ease of maintenance

Development Management: Meet business objectives

• Minimize number of coding styles across projects

• Support budget and time constraints

• Improve capability to size projects

• Promote growth of developer knowledge and skills

• Minimize personnel turnover

• Minimize requirements churn

• Avoid increasing scope

• Minimize the number of surprises

• Maximize developer efficiency and effectiveness

• Maximize ability to reassign personnel

• Achieve organizational objectives

How well do these criteria match your data technology evaluation and incubation process? I look forward to reading Joe's report detailing how LINQ, ADO.NET, and the Entity Framework rate against the framework.

I say Data, You say D-ah-ta

Blogger: Lyn Robison

Data is used both as a plural noun and as a singular mass noun. Data consists of raw observations. Data is (or data are) pieces of information without context.

In IT, do we deal with data or do we deal with information?

Consider the fact that information is data in context. Information has meaning, where data might not.

Businesspeople tend to have greater understanding of the contextual meaning of data than IT people do. So it seems like businesspeople deal more with information, and IT people deal more with data.

Based on this line of thinking, in my communications on this topic, I plan to use the word information from a business perspective and the word data from an IT perspective. That approach would seem to form a clear line of demarcation between to the two terms.

So, when you see me talk about information, think business. When you see me talk about data, think IT.

Data Modeling in COTS or SaaS Applications

Blogger: Lyn Robison

In my previous post, I talked about the value of logical data modeling. But what do you do if a big portion of your data model is locked inside COTS or SaaS applications?

Many enterprise applications are tightly coupled with their data. Valuable information is often trapped inside enterprise applications. This is unfortunate because to maximize their value, applications and information are best managed separately.

The fist step to liberating enterprise information from the grip of applications is to model that information at a logical level, even if – especially if – it is buried inside of enterprise applications.

Application vendors could do a lot more than they are doing to help you create logical models of the information that they hold. I will present more on this topic at Catalyst in June, but it turns out that some SaaS vendors are doing more to make their information readily available to you than COTS vendors are.

You might think that you can get at the information more readily from COTS applications then you can from SaaS applications. After all, COTS applications store their data inside the walls of your enterprise and SaaS applications store data outside the walls of your enterprise in their own data centers. But the truth may surprise you.

Some prominent SaaS vendors offer APIs for accessing your information directly, outside of the application. Through these APIs, SaaS vendors are in essence publishing a logical data model. The data model is probably incomplete, and must be inferred from the API, but at least it is there.

The majority of COTS vendors provide absolutely nothing for you in terms of a logical data model. With a typical COTS application, you have to try to infer the logical data model from the database schema, from data entry screens, and from reports. Not an easy task. Progressive COTS vendors will provide a service-based data access layer for their applications, but those vendors are few and far between.

Logical data modeling can be messy and difficult to do, and the reward is the ability to decouple your information from your enterprise applications so you can manage them separately and optimize them both. Application vendors could help you do this. Through my Catalyst talk and through reports that I will publish in the coming months, I will try to talk application vendors into making logical data modeling easier for you to do.