Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Architectural Layers for Standards


Published on

Group output generated out of the Microsoft UK Architect Council Meeting at Bletchley Park

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Architectural Layers for Standards

  1. 1. Standards & Interoperability Presenter: Ian Race, Bank of America Facilitators: John Phillips, Microsoft Giampiero Nanni, Microsoft Team: Bryan Boreham, Barclays Capital Roger Wagland, Clifford Chance Tim Gregson, Microsoft In relation to one of these areas: What does interoperability mean in this area? What are the challenges/opportunities? What does interop have to deliver?
  2. 2. Architectural Layers Layers Interoperability characteristics Business Business agreements drive the requirements for process standards from the top level. Goal of interoperability is automation of process and reducing operational risk (e.g. Manual format translation...). Internal processes: BACS and SWIFT are examples of standardized processes for some businesses (banking); but in other businesses (legal) need custom processes that still provide essential precision – need for standards for creating good business process to reduce operating overheads and stay more agile - but such standards are not top of the problem list. However interworking is also needed with governments and external customers: purchasing, billing, payroll are external business processes that are often solved as custom systems.
  3. 3. Architectural Layers Layers Interoperability characteristics Application Mostly the key issue is standards for information transfer (not specifically documents – but records do need to be kept and made reliably available/discoverable for a long while). XML works well + application-specific schemas for the semantics. Have to deal with whatever input document format within reason (e.g. ODF, OOXML) is provided by customers and clients. Content standards are useful for things like frequently used contracts. These also need assurance of origin, validity, signature etc. (might be provided by security standards in infrastructure layer). Infrastructure/ TCP/IP (e.g.) – becomes invisible as more value is provided by higher Technology layers. Challenge: IPV6 – discontinuity like this in infrastructure needs a migration story to allow the infrastructure to remain interoperable. Standards are expected – to allow this layer to support value at higher layers. No discussion of Web Services / SOA!