XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Argument: Software design is important, data design is not

I'd also give a good use case for data design, a real world example that's in the news today ... ObamaCare.

The American Care Act (ACA) was designed around two primary components - a Federal Funded Exchange (and some state exchanges) or FFE and the Data Services Hub (DSH). I worked as a data architect on the DSH side, though because of the byzantine way that the organization was set up, I had comparatively little ability to push through most of what I felt made for good data design.

The biggest problem with the program was that the key decision makers felt that "software was more important than data" in a project that was ultimately built around moving data around. This meant that you had software developers writing Enterprise Service Buses and SOAP service portals (can you say Java shop?) long before anyone had any idea about what would actually be going through the pipes. The DSH, which was responsible for taking in the FFE products and performing verification with Social Security, Medicare/Medicaid, the IRS, Homeland Security, the Veterans Administration and (believe it or not) the Peace Corps was seen not as a central data repository (despite the fact that it was central to just about every process) but simply as a conduit, while the FFE (which was responsible for the front end) ended up with the databases.

When I came aboard, each developer was creating their own ad hoc XML structures, based primarily on the recommendations of business analysts who were for the most part told by the FFE that they needed this element to support their own ad hoc development process. There was no attempt made to standardize on data structures, no logical data models, not even ERWIN diagrams. Given the distributed nature of the applications, this could have actually made for a good RDF test case - consistent identifiers used across multiple systems, an open world assumption about data availability, the ability to associate multiple identifiers from different namespaces with explicit bundles and a heavily graph oriented resource distribution - but because it didn't fall into the mandates of the "software" that the system architects knew, this didn't even begin to happen. In the end, I was able to manage to get NIEM used, and even helped to push the idea of canonicalization of the data architecture, but by then the damage had been done.

The FFE began coding literally from the time the contract was inked, because this was seen as a "software" application. Everything was messages queues and pipes and services, and the specific structure and consistency of the data was seen as a non-issue. (It also meant that the GCs could start charging for butts in seats from day one.) In the end, what this meant was that web developers were working with myriads of inconsistent ad hoc data structures, typically working with them in Java rather than via transformations, and keeping as little of the relevant data out of databases as possible. You couldn't optimize your interface design, your data types were limited to the most primitive databases out there (a big argument ensued at one point because some databases had an 18 character limit for names) and internal validation became nearly impossible. This led to matches on top of patches in the code, and each patch reduced the overall integrity of the system.

This shouldn't have been that hard of an application. If the time had been spent up front in good data design and moving towards a resource centric rather than message centric approach, the project would have been functional in six months and fully operational in ten.

So yes, I think data design is important.

Kurt Cagle
Principal Evangelist
Semantic Technologies
Avalon Consulting, LLC
443-837-8725

Kurt Cagle
Invited Expert, XForms Working Group, W3C
Managing Editor, XMLToday.org
kurt.cagle@gmail.com
443-837-8725



On Tue, Nov 12, 2013 at 9:29 AM, David Lee <dlee@calldei.com> wrote:
This whole thread is silly.
All software and programs are just bits (or qubits or "information units" or whatever) and there is nothing fundamentally different between any of them.   Therefore by extrapolation all software and data are equally useful or not useful depending on how you want to naval gaze.

Similarly in engineering.
All things are made up of matter and energy which any high school student can tell you is made from subatomic particles and maybe some dark energy and E&EM tossed in.  So clearly if you know how they work you can design an aircraft or a car or a human equally easily.

Q.E.D.


----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org




_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS