Repositories are a 'force multiplier' for SOA
Everyone's talking about SOA, but who's really got one? We may have Web services by the dozens, but the impetus is on being able to track and manage those services.
That leads us to the whole subject of repositories. In a chat I had earlier in the week with Infravio's Miko Matsumura, he noted that 'repository' may be running the risk of becoming 2006's "most abused word." Nevertheless, at this stage in the game, we need them.
In a new ZDNet post, Brent Carlson, vice president of technology and co-founder of LogicLibrary, warns against getting caught up in the excitement around the recent acquisitions in the SOA space (Datapower, Systinet, and Actional) and remember that they're serving markets that haven't quite come into existence yet.
These acquired companies primarily serve the "tail end" of the SOA process, namely a well thought out and executed SOA initiative. To get there, organizations need to get past the ABOS, or A Bunch of Services, stage that they're mired in. (I've called it JBOWS, or Just a Bunch of Web Services, but I guess Carlson's definition is a little broader.)
Carlson provides some advice for organizations seeking to move from ABOS/JBOWS to SOA. Namely, to "put in place a combined design-time software development asset (SDA) repository/registry to support the architecture and software development lifecycle (SDLC) governance environments within that SOA."
The SDA repository can support the service production side, "with links to file-level repositories like SCMs, document management systems, defect tracking tools, requirements management tools, etc. for SDLC work products." Also, the SDA repository can serve "as a registry on the service consumption side, preferably with deep integration into the developer tool of choice these days, the IDE."
Of course, the bits and bytes of repositories and registries are but a tool, and tools only work when properly used. Carlson states that success rests on the level of communication between design teams an the rest of IT. (I would like to add that the business end users need to be kept informed and involved as well.)
"The once-a-year IT pow-wow where the EA team rolls out its vision for the next set of strategic initiatives is a highly ineffective way to deliver core IT knowledge. ...design-time repositories serve as a 'force multiplier' that enables enterprise architects to consistently capture and automatically deliver their knowledge to the larger IT community."