Today, Macehiter Ward-Dutton Ltd. (MWD) published report of the study on the role that IT Architects play in BPM initiatives. The MWD worked in conjunction with the partners at IASA (International Association of Software Architects) and the study was conducted among the IASA members. Since I have contributed a few questions into the study questionnaire, I feel entitled for some special comments on SOA related topics.
The questionnaire was responded by 135 people from around the world:
who work for organisation of wide range of size:
The respondent roles were also quite different:
In the report, the MWD has created two categories of BPM adopters - "Leaders" and "Followers". I would not necessary agree with such categorisation but the study materials as they represented do not allow me any other grouping names to use. According to the MWD, the Leaders were those who reported clearer, simpler accountability/ownership structures than others, the Followers.
I am not sure if we may call this study representative but it has confirmed that "The resulting study provides strong evidence that those organisations that are most successful with BPM initiatives ascribe key responsibilities to IT architects, and further that in those most successful organisations the role and value of IT architects is clearly understood by other important groups", which is theoretically expected result.
After saying all this, let me turn to the theme of BPM - SOA relationship demonstrated by the study. Since the questionnaire was organised as a set of topics with detailing questions, I have composed a table on BPM - SOA for your attention.
As the MWD comments, "Most commonly, the relationship between BPM and SOA is seen primarily as one of technical complements - where BPM is seen as a way to make it easier to create composite applications from services, and SOA is seen as a way to make it easier to integrate automated processes with existing applications, systems and data sources". I do agree with the MWD on describing of this misconception. It is a classical IT point of view that cannot see 'out of IT box' and has been made with no or very little analysis of what business processes and service orientation are.
The MWD expresses its opinion on the subject, which I totally agree with: "the concepts of "process" and "service" are most effectively combined by thinking about them as complementary architecture viewpoints: processes are models which help us explain how outcomes are achieved, and services are models which help us define commitments to deliver those outcomes."
The study results show that "BPM and SOA are seen as business as well as technology initiatives". Such conclusion requires a certain level of maturity of comprehension of service orientation. The Leaders, who really crossed IT boarder into the Business have constructed understanding of the superposition between SOA and BPM, i.e. between WHAT/WHY/WHO and HOW. At the level of architecture, especially departmental or enterprise architecture, HOW does not really matter. HOW is important for realisation of WHAT but may be changed at any moment to meet new business needs.
Process as it is defined today is the least flexible model for changes. This is why so much attention is dedicated to the process management. However, enhancement of the process management is a treatment of symptoms instead of the problem itself. The study results tell us that 30 % of experienced and practical Leaders believe that BPM is a part of SOA; that 48% of Leaders believe that BPM and SOA are intertwined (in my opinion, they are interchangeable because business processes implements business services and, in turn, uses lower level business services to realise its process activities); and even 38% of Leader see BPM as just a service orchestration (which is my point of view as well). These numbers clearly demonstrate a tremendous progress in acceptance of real concept of service orientation and its leading role with regard to other aspects.
I, probably, have to explain why I think that process management does not heal the problem. If you have got it already, you can skip this paragraph. The key word for the understanding of my opinion is 'change'. A business process in the dominant majority of organisations is viewed as a pre-defined ordered execution of pre-defined activities to be performed by a priory assigned entities (applications, operational teams, other processes). The business processes are not tightly tied to each other, a change in one of them may be not that big deal for others, but how easily it is to realise such change even in the scope of one process when everything is pre-defined? If you look at the process as a whole, you can see only inputs, outputs, communication interfaces and promised business results or real world effect. This is a standard description of the service. If you want you process to become flexible in the change adoption, you have to breach the rule of "pre-determination", i.e. externalise process business logic and untie the process action providers from the process by defining only required business functionality and interfaces for them. This is also a standard description of the aggregate business service or service orchestration. In other words, when we are 'hunting' for flexibility the business process management shrinks to the cases where used business services are currently implemented as manual operations. Overall, it is a service orchestration that commands which manual business service to engage and when, what workflow to initiate and where the results have to be submitted, not other way around.
Driving to ward the conclusion, I have to note that this study is based on opinions of mainly IT Architects; I think that the same picture will appear differently in the eyes of Business Architects and Business in general. Nonetheless, I am confident that the 'ice is broken' in IT and it moves toward close collaboration with Business on the service-oriented platform (including process-based implementation), which is much more than agility.
Leave a comment