Arizona Grand Resort, Phoenix, AZ : Oct 5-7, 2008

Workshops

Sunday, October 5, 2008


1:00 –
5:00 p.m.

Boardroom to Code: Best Practices and Case Study for Business/IT Alignment

Peter Herzum, President, Herzum Software

This thought-provoking tutorial presents software factories best practices evolved over the last 15 years of software factories setup, operations, and evolutions for small, medium and large enterprises. After a brief historical and conceptual background, and using real-world case studies, the tutorial analyzes and exemplifies methodological, architectural, organizational, and technical aspects of setting up software factories for development and integration. The overall software supply chain is discussed. Benefits, costs, business cases, and realistic results are illustrated, with focus on metrics, success criteria, and lesson learned. The tutorial addresses the required enterprise context, the relationship with other modern software and IT practices (such as enterprise architectures, IT governance, agile methodologies, cosourcing, and more). The impact of modern architectural styles (SOA, components) is illustrated. The impact of different technologies (Java, .net, Open Source), and of different commercial offerings are compared. This pragmatic tutorial provides a unique synthesis of modern software development and is guaranteed to greatly enhance your understanding of how to best solve today’s software challenges and balance the many trade-offs of IT.

1:00 –
5:00 p.m.

SOA and Domain Modeling

Ashton Thorogood, Enterprise Architecture Team Lead, SIG, LLP
Scott Scalf, head of SIG’s Enterprise Technology Group

SOA, as a technical strategy for system inter-operation, is becoming a well accepted architecture in many companies. Though in principle technology agnostic; one specific implementation of SOA, Web Services, provides a very effective integration "Glue"; particularly for legacy systems. While this type of integration provides some benefits, in technology intensive companies that develop their own mission-critical software, such as Capital Markets, the full potential of SOA cannot be realized if Services are not recognized to be part of a larger Enterprise Information Management Strategy. As such, Services provide interfaces to Enterprise data using a consistent, unambiguous language, thus enabling the semantic reconciliation of related domains. This approach supersedes older methodologies that either relied upon point to point transformations, or integration at sub-system levels; e.g. common data models on shared database instances. Both of these lead to the tight coupling and inconsistency that are antithetical to SOA. Services allow specific systems to optimize their private data for their own needs while at the same time providing a mechanism for the provision of data to downstream. If Services provide the "How", it is the Domain Model that more importantly provides the "What". A Domain Model defines a "Semantic Ontology", a formal structure of meaning, or language with which to describe the business activities of the enterprise. Common language, particularly English, is notably imprecise and relies heavily on interpreted context. This does not help architects and engineers who require a stricter formalism to define their models and systems. It is important to note though that Domain Models are not System Models and like SOA are technology agnostic. While a Domain Model defines a more precise grammar, it remains unlikely that business users will adopt it, or even if they attempt to, that they will always use it correctly. It is therefore incumbent on technology professionals to use the Domain Model as a “Rosetta Stone” to perform any required mental translation when obtaining requirements or in any other interaction with the business. Data models transactions, master data, etc.) should conform to the Enterprise Domain Model and keep in mind not only transactional uses, but also requirements for eventual analytic use. It is therefore extremely important to capture the time dimension and understand the domain-consistent life states of the thing being modeled. Not only must state be captured, but also the reasons for change. This is where Services add a layer of understanding not formerly available by just executing an SQL query. Service methods should implement the “Verbs” of the Domain Model – these are the “Reasons” for a change in an object’s state. When considering these state changes, it is useful to consider whether what is being changed materially affects the nature of the object. Attributes or properties that actually result in a new thing are considered to be “Intrinsic” whereas others may be just “Descriptive”. Ultimately the thing being modeled may be represented in downstream analytic systems (data warehouse and data marts) as both a dimension and a fact unto itself.