How Business Architecture Helps SOA

Posted by Tom Dwyer on Tuesday, February 2, 2010 - 13:33

Rate this:
Total votes: 0

SOA is perceived as a best-practices approach for building software systems and hence does not involve the business in its design. In this scenario the burden falls on IT to demonstrate the value on SOA and how it aligns to business strategy. The only way to achieve this alignment is through a business architecture approach. Has anyone created an SOA that aligns with the business strategy without taking a business architecture approach?

Comments

Login or register below to comment on this discussion.
Pierre Gagne
,
posted 3 years 4 weeks ago
We only work with insurance and wealth management clients. We have not seen clients building SOA applications without a business architecture or at least a business architecture framework. We have seen a number or clients that did not have any refernce to build SOA applications. So to assist or clients that have nothing or want a start to build an enterprise business architecture, we provide them with a FREE capability map and an enterprise business architecture framework for the insurance and wealth management industry. It is called Panorama 360 and it can be ordered Free of Charge for the financial industry at www.InsuranceFrameworks.com. If you want more details, write to me at Pierre.Gagne@insuranceframeworks.com.
Frank Millar
,
posted 6 years 43 weeks ago
I agree with Dennis that Tom's assertion, "SOA is perceived..." is interesting because the perspective is outside of my experience. The way that I look at this stuff, Services Oriented Architecture is a dependency of the Business Architecture, which is in turn, a dependency of the Enterprise Architecture. The larger the organization, the less likely that org will be ready, willing, or able to do a full EA. Nevertheless, an EA that is cursory/superficial/incomplete for the whole organization can set an important foundation for a deeper dive into a targeted area, starting with the business architecture. Among other elements, the business services of this BA should be clearly identified. This sets the stage for an SOA that is traceable all the way back up to business operations strategic goals that support the enterprise strategy. Services Oriented Modeling and Architecture (SOMA), an IBM favorite, offers a step-by-step approach for creating a SOA, and this method can be dovetailed nicely with a business architecture that includes its business services clearly identified. I've held that this dovetailed approach has merit for some time, only to have my perspective on this reinforced during my first reading of TOGAF9. That standard more or less debunks certain SOA methods (I think the TOGAF9 authors might actually be referring to SOMA!) as too technically oriented and insufficiently business oriented. I'm comfortable that this dovetailed approach addresses the issue expressed in TOGAF by deliberately threading the helpful SOMA method back into the services elements of the Business Architecture. I believe that TOGAF is working on a more business-centric focus for SOA. It will be interesting seeing what The Open Group ends up putting in the standard. [Updated on 4/24/2010 8:53 PM] [Updated on 4/24/2010 9:11 PM] [Updated on 4/24/2010 9:14 PM]
Dennis Djenfer
,
posted 6 years 43 weeks ago
I believe best practices in building software systems is to involve all parts of the business that has knowledge and interest in the problem domain. If the problem domain spans over the whole enterprise, then the people with this kind of knowledge and views must be involved. In the latter case, as far as I know, some kind of business architecture approach is regarded as best-practices, regardless if you are pursuing SOA or any other architectural style. However, I don't think the business architecture approach means the same thing for everyone. Some people may interpret this as a process centric approach, others interpret it as a business capability approach, and some may even think of this as a holistic information centric approach. The scope of the approach is also something people debate, if one should involve the whole business at once or if it should be a more iterative approach. Of course, there are other approaches, e.g. survey all legacy systems, try to consolidate them and put services in front of them. I believe it's a quite common approach but I don't think it's regarded as best-practices for SOA. [Updated on 4/23/2010 4:19 PM] [Updated on 4/23/2010 4:20 PM]
Tom Dwyer
,
posted 6 years 45 weeks ago
I was referring to the creation of a business services architecture for the entire company and not to a domain-specific software system. Many IT people report that after the business and IT discuss the business requirement for such a domain-specific system, IT determines how to address it and defines a technical approach using SOA. The business does not get involved in that technical specification.
Dennis Djenfer
,
posted 6 years 49 weeks ago
I'm a bit confused about this statement: "SOA is perceived as a best-practices approach for building software systems and hence does not involve the business in its design." Why do you think a best-practice in building software systems precludes the involvement of the business? Where does the requirements for the systems come from in that case?

Join the Discussion

Already a Member? Login Here:

Shopping cart

View your shopping cart.

Editorial Directors

Gregg Rock
Gregg Rock
Editor & Founder
BPMInstitute.org

Andrew Spanyi
Editorial Director
BPMInstitute.org

Jeff Scott
Editorial Director
BAInstitute.org