What is an SDA? An SDA is something of value to an IT organization, including: –Knowledge assets Architectures Best practices and processes Design patterns … –Executable assets Web services Data views Components Applications … SDAs are composed of metadata, such as: –Artifacts: work products, such as code, schemas, models, executable modules, … –Classifiers: searchable and reportable values such as keywords, development effort, owner, language, … –Relationships to other assets: dependencies, prerequisites, other asset versions, …
SDA Development Lifecycle Analysis + DesignCodingTesting + QADeployment Use Cases Requirements Technical Models SCM Systems Test Cases Business Process Models Documentation Best Practices Design Patterns Tracking System/ Repository Documentation and Training Materials
SDA Contexts In order to be fully understood and managed, SDAs need to be placed into the following contexts: –Application architecture context –Technical architecture context –Business architecture context –Deployment architecture context The first three contexts directly affect the software development lifecycle
General-purpose utilities, APIs, Abstract Data Types, System Service Components Domain- Independent Layer Microprocessor Business Components Financial Business Components Insurance Business Components Domain- Dependent Layer Intel App#1 Components Intel App#2 Components Citicorp App#1 Components Citicorp App#2 Components Allstate App#1 Components Allstate App#2 Components Application- Specific Layer 100% up to 85% 15-20% 0% Application Application Context: Three Classes of SDAs Amount of application
Insurance Business Components General-purpose utilities, APIs, Abstract Data Types, System Service Components I.T. Business Components Financial Business Components App#1App#2App#1App#2App#1App#2 Mapping SDAs to the.NET Technical Context
Business Context Technical and application contexts are only part of the story –Its just as important to align your reusable asset development work with your companys business context What is a business context? –The overarching business requirements driving development projects New component/service development, application integration, new/reworked application development –In other words: What business processes really matter to our company? And what business functions are demanded by those business processes?
UML as a Means to Express Business Context Consider using UML to document your business context Primary UML construct is class diagram laying out coarse-grained reference components/services Other UML constructs to consider: –Use cases Establish initial requirements for business function Actors Preconditions Functional scenario / use case steps –Activity diagrams Describe detailed process or subprocess flow underlying a use case Specific activities can be mapped to functional capabilities to be implemented as Web services, components, etc.
Expanding Our Business Context Sample Use Case Diagram
Expanding Our Business Context… Drilling into Sell Items Activity Diagram…
Expanding Our Business Context… Associating Convert Currency Activity with Component…
Putting our SDA into Business Context Returning to our component model… –Map our reference component to our example asset Reference component operationComponent method getSupportedCurrenciesgetCurrencyCodes defineSupportedCurrencyno direct equivalent convertCurrencyValueconvert defineExchangeRatesetExchangeRate deleteExchangeRateclearExchangeRate
Emerging Business Process Standards: A Business Context Source Significant industry movement away from EDI towards standardized, XML-based business process and messaging definitions –Web services and service-oriented architectures (SOAs) are accelerating this trend Examples of business process standards: –RosettaNet: supply chain –ACORD: insurance –IFX: financial services –ebXML: electronic business/trading
Emerging Business Process Standards Advantages: –Can learn from industry best practices and experience XML-based message sets Standard data dictionaries Reference business processes –Packaged applications are adopting standards as they move towards Web service-oriented APIs Besides, your business partners are probably already doing something here and will take you with them – whether you like it or not! –Intel: …13 percent of all our machine-to-machine, B2B transactions today are happening through the (RosettaNet) standard – roughly 30,000 transactions a month.
SDA Reuse Organizational Roles SDA reuse is supported by production/ distribution/consumption roles –Production: Identification and preparation of existing and newly-defined candidate reusable SDAs –Distribution: Publication of those SDAs into SDA library –Consumption: Use of SDA library to discover appropriate reusable SDAs on a per-project basis
SDA Production Strategies Consider creating a virtual/matrixed SDA architectural review team –Team members: Team leader dedicated to SDA reuse program Matrixed team members drawn from project teams Lead designer/developer skills required 10%-20% job responsibility –Team objectives/responsibilities: Identify candidate reusable SDAs – active discovery Review proposed reusable SDAs – asset hardening Adherence to architecture Necessary functionality implemented and supported Mandatory artifacts provided Publish approved SDAs into SDA library for consumption Recommend future resource allocation for key reusable SDAs Expanded funding for key SDAs Transfer of key SDAs to common SDA support group
SDA Distribution Strategies Distribution scalability typically requires use of an SDA library to distribute assets –Asset metadata assembly and validation Standardized metadata definition Per-asset-type metadata validation and enforcement –Asset publication Newly defined SDAs Updated SDAs New versions of existing SDAs
SDA Consumption Strategies For best SDA traceability/manageability, consider named user consumption Project-scoped interactions/tracking SDA acquisition Configurable approval signoffs based on organizations process Project and asset-specific collaboration Discussion forums Persistent searches Asset notifications In some situations, anonymous consumption can suffice Suitable for lightweight/casual users Read-only interaction with library Restricted tracking and collaboration activities
Summary To be effective, SDA reuse strategies need to: Define technical and business contexts –Microsoft/J2EE have established two very useful technical contexts –Only your business analysts can define your business context for you – listen to them! –Consider using UML as an efficient means of communication Align existing application inventory against prioritized business processes –Dont boil the ocean. Pick the key systems that support business needs as defined by prioritized business processes. Manage the SDA production/distribution/consumption process lifecycle –Tools can help with delivering quality assets to consumers and tracking where those assets are used
About the Speaker Vice President of Technology and Co-founder, LogicLibrary, Inc. Named to InfoWorlds list of CTOs to Watch in 2004 17-year veteran of IBM –Lead architect on WebSphere Business Components Project –Held numerous leadership roles on the IBM SanFrancisco Project Co-author of two books: –Framework Process Patterns: Lessons Learned Developing Application Frameworks (with James Carey) –SanFrancisco Design Patterns: Blueprints for Business Software (with James Carey and Tim Graser)