Designing an enterprise's SOA to work with other corporate initiatives has been cited as a very significant challenge facing SOA projects. Besides Web services, one must cope with business
The good news is that the tools of the SOA trade continue to expand. Yet that surge of expansion can present challenges. UML, although not without its detractors, has settled in as a commonly used approach to designing systems. A good thing about UML is its extensibility. Practitioners are now using UML in conjunction with TOGAF and other tools to create software models to handle the all-important journey from business idea to working system.
How do you build a useful tool set? Some advice from an expert may serve as a guide. SearchSOA.com recently asked Ramsay Millar, practice leader with a consultancy and training firm called Integrate IT LLC. Millar explained in an e-mail interview how SOA specialists and solutions architects should apply modeling to architecture – what they should do and what they should look out for.
Millar told us that software and solutions architects today are often very confused. This is in part due to the fact that they do not have an established reference architecture or usable language (or enforced manner of speaking) for communication with various stakeholders in the organization.
''The job title – architect – is a fast way up the ladder, but few who are climbing have strategic business modeling or abstracted building-block knowledge and experience,'' he said. ''We need highly skilled and practiced architects ... to create a business architecture reference model.''
Successful software architects will find a working reference model that matches their enterprise – this becomes a framework they can customize with added ''tools,'' Millar indicated.
What are the some of the elements of Millar's own tool bag?
He employs UML and an extended TOGAF 9.0 reference model. Add to that the OMG BMM, BPMN and SBVR, customized for his uses.*
''SOA is all about articulating the business and then driving services – not the other way around,'' said Millar. Like others, he has seen the results of failed SOA projects.
"The first thing that I ask my clients is 'Why did your journey to SOA fail?' – the answer I get most often is 'the business (side) is siloed, and cannot articulate business models and strategies.'" But the IT side is siloed too, he admits.
''Architects need to become more collaborative and agile and involve all points of view in their models. They need to come out of the glass house, and become involved with gaps between 'as is' and 'to be' business transformations,'' he said.
At present, it seems, too many people see services in terms of technology. They should see them in terms of businesses. Until a language for that comes along, a variety of tools, used well, provide ways to deal with that significant gap on the road to successful SOA.
* Ed. Note: Put another way, he ''employs the Unified Modeling Language and an extended The Open Group Application Framework 9.0 reference model. Add to that the Object Management Group Business Motivation Model, Business Process Modeling Notation and Semantics of Business Vocabulary and Business Rules, customized for his uses.''
This was first published in August 2011