Joe McKendrick has a great post on how system architecture these days is in a state of flux - there are a collection of web services floating around, sort of talking to each other, sort of not - the dream of a streamlined, service oriented architecture seems to be still largely that. He suggests that the secret lies in the repository - in having a central design-time asset where organisations can build out from a single repository to a SOA.
Now, I find this interesting for several reasons, but mainly because since I started with TOWER Software, four years ago, I've built several different business systems, and I've never buit a relational db store for any of them - I've alwys just used TRIM Context as the repository. Sure it's designed to manage enterprise content - but that can include custom designed content types that map to a business object, just as easily as it includes a document, or some web content.
With the web service interface, and the new ICE framework for building interfaces, it's easier than ever to build an entire functional business that attaches to one repository - which means that separate systems are built as services with a common back end.
It's not exactly the grand unification that we were promised at the dawn of the SOA era, but it does mean that the loosely coupled services are in existence, and it also means that you can get in step with the DRY (Don't Repeat Yourself) way of thinking - security, access control, and display logic are all taken care of by TRIM, and you can design your services to be focussed solely on business logic.
I think that repostiories are going to be an interesting area to watch - and I suspect that at some point in the next few years, some industry analyst will announce the "Death of the relational database..."
Now, I find this interesting for several reasons, but mainly because since I started with TOWER Software, four years ago, I've built several different business systems, and I've never buit a relational db store for any of them - I've alwys just used TRIM Context as the repository. Sure it's designed to manage enterprise content - but that can include custom designed content types that map to a business object, just as easily as it includes a document, or some web content.
With the web service interface, and the new ICE framework for building interfaces, it's easier than ever to build an entire functional business that attaches to one repository - which means that separate systems are built as services with a common back end.
It's not exactly the grand unification that we were promised at the dawn of the SOA era, but it does mean that the loosely coupled services are in existence, and it also means that you can get in step with the DRY (Don't Repeat Yourself) way of thinking - security, access control, and display logic are all taken care of by TRIM, and you can design your services to be focussed solely on business logic.
I think that repostiories are going to be an interesting area to watch - and I suspect that at some point in the next few years, some industry analyst will announce the "Death of the relational database..."
Don't worry about buying another code - I'll send it up with Fuzzy
ReplyDelete