archive-org.com » ORG » J » JEFFSUTHERLAND.ORG

Total: 379

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Business Object Design and Implementation
    work item that is the designated task of X3H7 Goal of the Workshop The goal of the workshop is to facilitate development of design patterns and frameworks for building business object systems A common business object infrastructure is essential to an object oriented software platform that enables systematic reuse of components across an enterprise Of particular concern is the infrastructure required for supporting domain specific business object models At a recent Object Management Group meeting BOMSIG outlined four layers of object technology for standardization Distributed Object Layer CORBA OLE COM Component Interoperability Facility Business Object type Business Process Object and Business Entity Object subtypes generic functionality subtypes of Business Process Objects generic data specification subtypes of Business Entity Objects Common Business Object Layer Customer or Part as subtype of generic functionality object Order as subtype of generic data specification object Domain Specific Application Frameworks Will need to have a consistent infrastructure to be widely used within and across industries The concepts for this infrastructure are just beginning to emerge as standards for the distributed object layer are stabilized by the Object Management Group and individual software vendors Papers addressing issues related to component interoperability and common business objects were solicited from academia government and industry for the workshop Presented Papers Business Application Components Tom Digre Texas Instruments The software industry has been struggling with how to produce software IC chips for years with little success Meanwhile the custom chip industry has learned how to shrink wrap software embed it in hardware and market custom chip sets This is the model of the future for software distribution Business Object Architectures and Standards Cory Casanave Data Access Corporation As the Chair of OMG BOMSIG Cory presented the latest thinking of the committee on the business object infrastructure that is needed to support large domain specific frameworks in finance manufacturing heath care amd insurance His paper summarizes the current BOMSIG view of a Business Application Architecture Implementing Business Objects CORBA interfaces for legacy systems Thomas Grotehen and Rene Schwarb Swiss Bank Corporation SYSTOR In 1991 the OMG defined an architectural framework OMA Object Management Architecture as a milestone in realizing the vision of distributed object oriented computing This paper describes an experiment designed to examine whether an OMA CORBA Common Object Request Broker Architecture implementation can be successfully employed in the existing information technology environment of a bank It provides an overview of both the benefits and the problems involved and an outlook on future technology developments in this area An Architecture Framework From Business Strategies to Implementation William Hertha Jim E Bennett Frank J Post Ian M Page Canadian Imperial Bank of Commerce Business systems architects and their clients increasingly suffer from information overload To help businesses to partition and relate the kinds of architecture information they must build and share we propose a framework consisting of three related models each incorporating four tiers of subject matter connected by use cases An Architectural Framework for Semantic Inter Operability in Distributed Object Systems

    Original URL path: http://jeffsutherland.org/oopsla/oo95summary.html (2016-04-27)
    Open archived version from archive


  • oo96final
    Fowler 96 Business Objects Business Patterns Paul Evitts Christopher Alexander s notion of patterns as a way of seeing and building the world in a manner that is natural self reinforcing self maintaining and ultimately good has influenced information systems design practices a great deal recently And even though systems pattern thinking has been largely a bastardization of Alexander s underlying concepts the results have been powerful Emboldened by the success of systems patterns and prompted by an interest in revisiting Alexander s ideas directly Paul Evitts has been working with some colleagues on applying pattern thinking to business strategy modeling and analysis thus extending the idea of Business Objects in a variety of ways While still exploratory the results have been encouraging In particular they reinforce the recent efforts by Booch amongst others to formalize the role of patterns in the world of object orientation His proposal to classify patterns into frameworks mechanisms and idioms and then to incorporate patterns within Use Cases and to use Use Cases to detail patterns is very much in synch with the conceptual framework Evitts has been using Models of Business Objects Accounts Ralph E Johnson and Kazuki Yoshida University of Illinois at Urbana Champaign For business objects to be reusable they must be at the right level of abstraction Classes like Customer and Invoice will not be very reusable because they are too specific and each company will have its own version of them On the other hand classes like Business Object and Business Transaction are too general We don t need another general purpose object model Reusable business objects will have to thread the gap between solutions that are too specific and too general There will not be a single model of business objects Instead there will be a set of specialized models that work together The major research priorities include determining which models are needed defining each model and learning how they can be used together This paper describes Accounts a framework for business transaction processing which is an example of the kind of business object model that is needed It also describes the general problem of integrating different models of business objects and uses Accounts to explore this problem An Object Model for Business Applications Fred A Cummins Electronic Data Systems This presentation focused on defining a model for objects a generalized representation to be used in the development of business applications A business application includes any application used in the operation of an enterprise The enterprise might be a commercial business or it might be a government agency or an academic institution Cummins purpose is to define a level of abstraction to be supported by the Business Object Facility BOF that is the subject of the RFP issued by the OMG Business Objects Domain Task Force His concern is that the BOF should greatly simplify the effort required by application developers to develop solutions to business problems This presentation will help potential submitters understand the requirements for the BOF from an application developer s perspective Services of Workflow Objects and Workflow Meta Objects in OMG compliant Environments Wolfgang Schulze Markus Böhm Klaus Meyer Wegener Dresden University of Technology Database Group After the definition and adoption of basic object services CORBAservices OMG95a time has come for the Object Management Group OMG to address more abstract parts of the Object Management Architecture OMA The roadmap for the next standardization efforts and the restructuring of its organization clearly show that the OMG is preparing for this challenge The OMG has introduced four groups of horizontal common facilities Interface Information Management System Management and Task Management CORBAfacilities OMG95b The main responsibility of the Task Management Facilities shall be rule management object automation agents and workflow The OMG s goal that the Workflow Facility provides management and coordination of objects that are part of a work process see OMG95b p 5 3 is very vague and leaves much work to be done in order to arrive at a rigorous definition Up to now the OMG has not presented a precise definition of what they understand as a workflow in this context Even worse the placement of workflow functionality within the OMA is in debate too The publications of the OMG BODTF Business Object Domain Task Force clearly identify workflows as a special form of business objects consequently calling them business process objects This leads to the effect that they are either located inside a Business Object Facility or under the applications section of the OMA but not inside the Task Management Facilities Shulze et al hold the view that the original plan to introduce a dedicated workflow facility is the right choice and its rapid availability is of vital importance for the OMG The perspective of this workflow facility a clarification of the functions of workflow objects and their inseparable workflow meta objects is the key issue of this paper The Evolution of Enterprise Information Systems From Sticks and Jars Past Journals and Ledgers Toward Interorganizational Webs of Business Objects and Beyond William McCarthy Julia Smith David and Brian S Sommer Michigan State University This paper was a provocative discussion on the evolution of accounting systems Discussion in the workshop focused on McCarthy s contribution in the 1995 Workshop on the REA accounting model GM96 Workflow Meets Business Objects Mark Baker Northern Telecom Network Services Management 8 Sep 1996 The Workflow Management Coalition WFMC defines workflow as The automation of a business process in whole or part during which documents information or tasks are passed from one participant to another for action according to a set of procedural rules Workflow tools are typically composed of two parts The first is process execution This is the runtime portion of process management responsible for controlling and monitoring all the process instances currently active in the system The other part is process creation a graphical tool for constructing defining processes and support tools for deploying them Business objects automate business processes They need workflow capabilities by

    Original URL path: http://jeffsutherland.org/oopsla96/oo96final.html (2016-04-27)
    Open archived version from archive

  • oo96final
    Meeting in March 1997 Austin Texas This draft has been presented to the OMG Architecture Board for approval at the OMG Meeting in Stresa Italy With some minor modifications the final RFP OMG97b has been issued on May 9th 1997 The appointment of a workgroup to issue a Workflow Management Facility RFP overturned the Workflow Management Coalition s initiative Work96 to submit their non object oriented technology through a fast track process RFC without further discussion Essentially the Workflow Management Facility RFP has two key requirements Submissions shall provide a semantic definition of a workflow metamodel and specify a set of interfaces for workflow enactment The RFP states that the Workflow Management Facility defines interfaces and their semantics required to manipulate and execute workflow objects and their metadata see OMG97a p 1 This means that the OMG starts from the assumption that in a CORBA environment each workflow instance is realized as an individual object that exposes an interface Session 3 Enterprise Architectures Business Object Management Architecture Chris Marshall This paper describes a set of concepts by which an enterprise may be modeled The purpose of the enterprise is defined by its vision missions goals and objectives Business processes define the way in which this purpose is achieved Resources are the things created and used to perform business processes and organizations provide the framework within which business processes and resources are managed This approach ensures that processes focus on achieving purpose through optimal management of available resources The concepts have been implemented in Java to illustrate the feasibility of the approach X3H7 ODP Update Open Distributed Processing and Business Objects Joaquin Miller The reference model of open distributed computing RM ODP provides a framework for specifying a system It is directly applicable to the specification of a business object This paper presents a very brief overview of ODP a discussion of the current ODP enterprise viewpoint work and a sketch of an ODP specification of a business object Business Process and Workflow Management in an Enterprise Resource Planning Context M G Riné le Comte The research described in this paper is related to business processes and workflow management in an ERP context Today there is a poor integration between ERP applications and workflow management systems However a combination of both worlds could lead to very powerful applications Our research is working towards such integration EMPOWER An Object oriented Business Information Systems Framework for Learning Organisation N Phillips D Patel Object oriented frameworks offer businesses the opportunity to greatly improve the flexibility and responsiveness of their information systems development effort Application level frameworks provide generic solutions to well understood tactical problems interface design peer to peer communications client server data manipulation etc Although successful exploitation of these frameworks is of considerable strategic importance application frameworks are essentially tactical tools they address the question how not what Domain level frameworks fall into two categories those that support the implementation of well defined strategic options e g SEMATECH s Computer Integrated Manufacturing CIM Works Tali94 and those that support information architecture development e g Hert97 This paper addresses some fundamental problems with architectural frameworks Session 4 Business Objects Beyond Business Objects C Spottiswoode Here we go a short way beyond my OOPSLA 96 Business Object Workshop paper Spot96 which was already where angels fear to tread Oh no here s that fool stumbling in yet again But how has he avoided the mines on that plain Now you see him now you don t Fingers prodding fingers burnt We ll just plant this fertile field with simple grain More specifically in this paper Where are we in Business Objects headed And how do we get there better Business Objects and Business Rules D Ehnebuske B McKee I Rouvellou I Simmonds Business object facilities should be designed to enable businesses to implement distributed object oriented business applications that reflect the natural structure of the business They should also provide structures that allow different views on the system to be faithfully captured in its design For example information technology experts and business experts have different but equally valid ways of looking at a business application system both must be captured faithfully if the system is to be useful flexible and durable Among the many areas of design an application development team must deal with is business rules This paper focuses on that area It outlines a patterned extension to a commercially available component architecture that enables enterprise applications to systematically externalize business rules The architecture though still in the proof of concept phase has been sufficiently implemented in several IBM engagements with business customers to demonstrate the feasibility of the approach The paper describes the architecture described at three levels the managed object level the business object level and the business component level each of which builds on what went before Revisiting Sims Mark Baker Oliver Sims is regarded as the father of today s business object movement in large part due to the success of his book Business Objects Delivering Cooperative Objects for Client Server Sims94 Yet despite the attention given business objects today much of his insight is apparently going unnoticed This paper contrasts attributes of the current popular view of distributed object systems with Sims vision Business Objects for Front Office Applications Making Domain Experts Full Partners J Bonar Front office applications are support tools for people interacting with customers They include applications like Help Desks Customer Call Centers and Sales Force Automation Front office applications are distinguished from other applications commonly treated in the business object literature in requiring 1 much higher levels of flexibility after they are installed 2 administration by domain experts rather than MIS personnel and 3 more extensive runtime browsing capabilities This paper discusses the use of business objects for implementing front office systems It concludes that business object architectures are well suited to front office applications particularly if the domain experts designing and administering the business logic details can do so directly without requiring programmers The

    Original URL path: http://jeffsutherland.org/oopsla97/oo97final.html (2016-04-27)
    Open archived version from archive


  • farm on meeting a requirement that the project doesn t know about Does SCRUM cover this point Great then SCRUM is the METHOD whereby this important principle NOT process contained in the model is carried out With reference to planning the CMM says don t take on a task without reasonable knowledge you have the wherewithal to carry it out Do you have to have 100 planning accuracy NO But if you don t know then KNOW you don t know and make that clear in your commitments to your clients Does SCRUM enable that Fine Then SCRUM or JAD or whatever is the METHOD whereby your company avoids inadvertently lying about its capabilities which is what the CMM planning is largely about anyway I read Chaos theory before I ever heard of the CMMs and it was immediately obvious to me that the CMMs could be adapted to the success criteria of the project at hand Where determinism was critical shuttle launch program for example then the CMM could be interpreted in a deterministic light Where adaptability is critical then the model can be used as a checkpoint for certain practices critical to adaptive approaches HEY EVERYBODY QUIT LISTENING TO THE PEOPLE WHO SAY THE CMMs ARE ONLY ABOUT OPERATIONAL EFFICIENCY There seems to be a popular opinion that the CMMs were written by a bunch of otherwise ignorant egg heads that came straight from a computer science class This just ain t so I have worked for three Software CMM SW CMM original co authors and I from them I constantly heard quotes from Juran Weinburg Mandelbrot Crosby Brooks DeMarco Lister Block Katzenbach Peters etc etc In other words the best industry knowledge was used as a balance a filter when evaluating how a CMM described principle could be applied in a given situation Many of the original works cited as sources of agile methods were written long before the CMMs and I can guarantee that most if not all of them had been read by members of the SW CMM team and had influenced the model s development Many of these concepts were alluded to in the SW CMM and have been made more explicit in the CMMI The bottom line is that trying to take a CMM and cram it into an estimating project control or operational efficiency box is very short sighted Once again we can blame this largely on DoD interpretations of the model being touted as the only valid interpretations I suspect that many authors of current literature are fully aware of this and simply are capitalizing on selling books to the youth market It gets funny when I see the word extreme tacked onto some practices such as JAD that have been around for years see ComputerWorld July 22 2002 Taking Projects to the Extreme But I digress let s revisit the idea of oversimplification Imagine walking into a 250 000 craftsman s shop opening a toolbox pulling out a hammer and

    Original URL path: http://jeffsutherland.org/scrum/Presson_on_CMM.html (2016-04-27)
    Open archived version from archive


  • All reduced to overhead and rubble Of course the kernels of modeling precision of expression thinking before coding and having a process persist but for many the weight of the commercial implementations have done their damage So some of the contrast and reaction of agilists to CMM and waterfall are to current implementations not the vision nor the intentions All of you have to is look at CMM as implemented at most major organizations or waterfall as implemented in such methodologies as Navigator to understand the damage I was brought into one CMM Level 3 shop because it was so badly implemented that development had literarally stopped Problems couldn t be reduced to an adequate level of agreement and definition to proceed with coding However the rest of the contracst occurs because CMM waterfall spring from a different theoretical basis than agile processes Increased precision and definition are at their core which is one of the alternatives for controlling a process However this approach only works when the definition and the problem have a mapping approaching 1 1 and the problem domain technical requirements and people is relatively simple It is typical to adopt the defined theoretical modeling approach when the underlying mechanisms by which a process operates are reasonably well understood When the process is too complicated for the defined approach the empirical approach is the appropriate choice Process Dynamics Modeling and Control Ogunnaike and Ray Oxford University Press 1992 The agile process is based on the empirical approach accepting the complexity of the problem and addressing it through frequent inspection and constant adaptation Empiricism is seen even in the Agile Manifesto where the signatories pose agility as an empirical counterpoint to a defined approach rather than as a new set of defined absolutes The various agile processes implement

    Original URL path: http://jeffsutherland.org/scrum/Schwaber_on_CMM.html (2016-04-27)
    Open archived version from archive

  • Business Object Design and Implementation
    change less than the specification of the tasks that they actually perform on the shared work objects Coordination structure also provides a micro level perspective Using this perspective there is no need to differentiate between intra and inter organizational interdependence and coordination The fact that coordination structure can be easily diagrammed is another significant advantage to the approach Coordination structure has been used to model inter firm technology arrangements Bai93 the design process of custom silicon chips Bai94a and the management of consistency between product development and standards evolution Bai95a Organization Structure Patterns Gamma et al Gam95 pp 6 7 provide the following format for describing software design patterns Pattern name and classification Intent Also known as Motivation Applicability Structure Participants Collaborations Consequences Implementation Sample code Known uses We propose that their format can be used for patterns of organizational coordination structure with the following modifications Coordination structure can be used to capture pattern Structure A case description of a business situation in which the pattern has been identified can been used to capture Motivation and substitute for Sample code A data dictionary can capture Participants and Collaborations in coordination structure patterns Pattern Classifications for Product Development Organizations Coordination structure patterns can be classified by application area and by topology of actor interdependences In product development application areas would include but not be restricted to the following external integration including the use of lead users and co development with users prototyping including throw away and evolutionary prototypes developed by internal and external design teams project team organization executive integration mechanisms such as gate reviews system integration and testing architecture development and relationships with technology suppliers The classification of coordination structure patterns by topology can be approached at various levels of abstraction To date three approaches have been taken First an analysis of 24 coordination structure models developed by graduate students in a course on system design management was used to develop patterns associated with the role of the system architect in system design organizations in linking product specifications with prototypes Bai94 A second approach was based on an in depth study of a single large software development project A five layered approach to modeling coordination structure Bai95b was adapted for use in a project organization environment The key elements in the five layers are actors and shared work objects alternatively Customer layer actors who define customer value including expectations requirements and standards purchase products provide resources Product layer shared work objects which embody customer value including expectations and requirements Value delivery layer actors who coordinate integrate interpret and deliver customer value allocate resources Design layer shared work objects which embody requirements of the design process including schedules and plans and the designs used by the value delivery layer to deliver customer value and Value creation layer actors who create customer value through design This five layered approach was used to identify patterns among the views of coordination structure held by managers involved in the project The third approach took a

    Original URL path: http://jeffsutherland.org/oopsla/bailetti.html (2016-04-27)
    Open archived version from archive

  • Business Object Design and Implementation
    serve to change an objects state Special interfaces Special interfaces are extensions to the component object interfaces for special application requirements Business Rules It is the reasonability of the component to enforce all rules that may be associated with the component Specialisation of components for Financial Services and Accounting Facilities Given the standard framework financially related components may then be defined as a subclass of the standard components The object model representing financial components is beyond the scope of this paper and may be suggested by other submissions the following is intended as a simple example Given the common CorbaComponent the interfaces required for the domain specific components would largely be related to the accessing and alteration of the components relations and attributes leaving it up to the component to enforce rules and side effects This provides a much simpler interaction model for components and one in which specialised interfaces beyond relation and attribute manipulation and event response would be the exception rather than the norm Simplifying component interaction serves to enhance interoperability and decrease complexity Specialised interfaces need only be defined for special needs The Requirement for OMG Standards Goals of standardisation The reasons to standardise components are directly reflected in the purpose of the OMG a to promote a single object oriented applications integration environment based on appropriate industry standards b to promote a framework for compatible and independent development of applications c to enable co ordination among applications across heterogeneous networked systems in a multinational multilingual environment d to adopt a core of commercially available implementations of this framework and to promote international market acceptance and use e to actively influence the future direction and development of these core products and technologies and f to foster the development of tools and applications that conform to and extend this framework and to provide a mechanism for certifying compliance with the core technologies Article I of the OMG by laws Such a purpose for OMG will have a range of advantages Synergy To synergize the work being done in creating business applications and distributed object components into a cooperative industry effort Interoperability To make independently developed components interoperable with a minimum of effort Federation of systems To allow diverse information systems to be integrated Ease of use To make the information understandable in business terms and easily meet business needs Open market To foster an open market in related components Both in pre built components and in tools for using and building components What needs to be standard With all the advantages of a standard there is a dark side also Restrictive standards can stifle innovation and poor standards can do more harm than good To minimize the inherent problems of standardization standards should be minimal That is they should provide a sufficient level of standardization to meet the goals but no more Simple minimal standards are also easier to adopt to future innovation Another question of a standard is its scope We are targeting information systems because of

    Original URL path: http://jeffsutherland.org/oopsla/casanave.html (2016-04-27)
    Open archived version from archive

  • Business Object Design and Implementation
    assume the responsibility for solution provisioning The business user will administrate business rules work flows and presentation The business user will specialize and assemble components into solutions using Enterprise modeling tools and toolkits The Information Technology provisioner will provision reusable components that can be combined to form solutions by the business user The IT provisioner will provision these components through purchase construction or specialization and assembly of finer grained components The IT provisioner will encapsulate purchased and legacy systems so they can be utilized as reusable inter operable components All provisioning roles are inextricably tied to components All roles specialize and assemble components In most cases the product of assembly is itself a reusable component Overall cycle time is drastically reduced by end user assembly of these components Building on this approach components can be used in several business solutions When a business condition changes the resulting modification to software is envisioned to occur only in those components directly associated with the changing business specification To support users in making their required changes the component based architecture should include an enterprise integration model which fully specifies the exposed services of all components and a set of tools The tools include business rule tools work flow tools presentation tools software assembly tools data access tools and so forth Component Specification The term component has been perceived defined and used in numerous ways throughout the IT industry a component may refer to hardware or software a software component may refer to operating systems data bases application packages or any other type of software there may be analysis design or other modeling components as well as runtime components Hardware network and fundamental software e g operating system infrastructure components currently have reasonable levels of plug and play interoperability This enables rapid and transparent installation replacement of tailorable infrastructure components within a broad range of reliability performance capacity and price characteristics These infrastructure components are no longer on the critical path to achieving objectives such as business solution cycle time reduction and end user empowerment The components which are on the critical path for meeting business objectives are Business Application Components Characteristics of Business Application Components include the following A unit or increment of functionality within the architecture that can independent of other components be added deleted enabled disabled or replaced A component provides a physical black box encapsulation of related services Universally accessible on the ORB Object Request Broker Interoperates with other components via the ORB Implementation and location transparency Clients are unaware of the location of server software components or their implementation details Component implementation and location can change dynamically without any modification to the client Programming language independent It is transparent to the client of components whether the component was implemented using Smalltalk C a CASE tool legacy application or a purchased component All component public interfaces are defined in IDL Interface Definition Language Defined in terms of a set of public services A component s services can only be accessed

    Original URL path: http://jeffsutherland.org/oopsla/digre.html (2016-04-27)
    Open archived version from archive



  •