Press "Enter" to skip to content

Best Practices for SOA Governance 1

now that we've got in the landscape of so a circa 2011 with our great case studies it's time now to drill deeper with our expert solo sessions and for this one I'm joined by Alistair Farkas and CTO at so a software Alistair welcome back thanks Poncelet composes at so uh software Alistair Farkas and spearheads product design and development and helps enterprise customers implement so our for ongoing business benefits he is a noted expert in custom application development distributed environments architecting scalable hardware and software and so and so a governance prior to joining so software he worked at us interactive where he was a key advisor to the CTO on many companies regarding internet architecture issues in his session best practices for civil governance Alistair describes three keys to successful solo projects clear business alignment measurable ROI and a more agile IT environment he also connects the dots to show how important it is to apply these Keys across the whole soul lifecycle from design development test deploy and update we'll see how so a governance has become one of today's most popular ways companies are accomplishing this balancing act just a quick reminder if you haven't already done so you can download Alistair slides by clicking the download button at the right and to ask a question simply type into the submit a question box and now Alice to tell us about best practices for solar governance thank you so not to repeat myself but certainly I think it's worthwhile to review sort of why it's a way in the first place I think that it's important to note that it's away is about transforming an IT department and it is about aligning that IT department ultimately with your company's business goals I think that a successful SOA strategy needs to provide the transparent business alignment it needs to have and demonstrate a miserable return on investment and it really needs to provide at the end of the day a more agile IT environment so let's look a little bit at the challenge the challenge that we found with SOA is that it's away is not about technology it's really something that is about people and processes so i would say that a successful SOA strategy is one that alliance first people and processes and then ultimately takes care of a technology that is going to implement and manage those people and processes so it's not primarily a technical problem and it cannot be solved by technology alone and it's also not something and I think that this is probably the key point here that people have sort of lost sight of it's not something that can be done outside of a business context or without any business support if I just think over the past sort of five years and think of the SOA projects that have succeeded and the ones that have failed the ones that have failed have typically been those projects that have had no business support no executive sponsorship no ability to actually meet their end goals and just end up with a bunch of technology that ultimately costs a lot of money and slows down your operational environment I think it's really important to establish the context of your SOA initiative within some sort of business goals and along with business support and I'm going to elaborate this as I go through my presentation so let's look at the common breast practices that I'm seeing and I'm going to talk anecdotally about these best practices and try and put them in the context of real-world scenarios or customer case studies the first best practice as you might have gathered is people process then technology I'm going to talk about how to take care of the people and processes within your organization and then ultimately start looking at technology speaking of technology there is a tool for every job the SOA landscape like many other technical landscapes within our day-to-day jobs is complex and there are many many tools that can do many many different things and there's always a danger that if you have a hammer everything starts looking like a nail so what I'm going to try and do is talk about which tools to get and which people should be using those tools and which function those tools should actually provide the third best practice I'm going to discuss it in to end I'm talking about how one should actually look at the entire life cycle then I'm going to also talk about integrating automate and I've covered this in my introductory session but integrating and automating provides returning investments and low total cost of ownership or a service-oriented architecture and then last but not least we also discuss what i call closing the loop which is essentially how do you actually provide a way of enforcing the policies and a way of implementing the policies in your environment with the minimal amount of impact so let's start at the beginning people processes then technology so we have seen SOA strategies initiated by different parts of the organization and if I look at the sales engagements we've had with our customers over the past few years I can see that we sort of CSR initiatives on three fronts the first one being an IT led initiative primarily an IT department is looking to monitor and secure their environment the problem with tackling it at that level is that it's very difficult for an IT department to justify new tools imagine if I'm an IT department and I want to go out and purchase some SOA tools and I go to the business and say well you know this issue a tool provides me with the ability of monitoring and securing my services the likelihood is they'll turn around and say well you already have three tools to do monitoring and five tools to do security why do you need another one and it's very very difficult to actually justify the acquisition of a set of tools that do monitoring and security without the context of a larger isso a initiative the second group of people we often interact with is development groups development groups are typically focused on a particular project or constrained within a particular line of business and their focus on services we find to be very bottom up so what I mean by that is they are trying to simplify their service development initiatives they are trying to perhaps simplify how they build services or perhaps provide or supply a repository of services to the broader organization now what we find with initiatives that are led by a development group is it's very often limited to a single project or line of business and in this case again it's difficult to justify the purchase of a tool and you very often don't have enough carpet in the organization to create best practices that are applicable for the whole organization and what you end up having is you end up producing services that nobody else uses and nobody else cares about you end up spending a lot of money building those services without any miserable return on investment the most successful projects that we encounter are ones that are driven and led by enterprise architecture CIO office of the CTO that kind of group within the organization these are most successful because they are driven by the business and they have sufficient support to implement change across the organization they are essentially responsible and capable of leading a transformation initiative within the company they are also capable of realizing a return on investment not because they are technically more competent but just because they are more capable of aligning the service initiatives with what's going on in the business they are more capable of getting the levels of reuse because they have access to a larger organization the problem that you might already know or be aware of is that it's sometimes difficult for these organizations within a company to generate the consensus and budget that they require so they often have to go to each of the project teams and each of the lines of business and get their consensus and financial support to implement an SOA we do however find that to be a simpler problem to solve than one there comes up through the other two avenues where you've both a bunch of services and no one cares about them or you're just implementing another monitoring and security tool and it's lost all recognition as being an SOA initiative in the first place so our most successful projects are ei EIO office of the CTO lead and that's simply because the problem is not one of our technology but rather one about people and process and business alignment and in many cases politics within an organization simply because this is a strategic and transforming initiative within a company so let's look at the next best practice choosing the right tool for the job so in my last slide I hopped on about people and process and getting the right sort of support within the organization and I mentioned that tooling is tertiary to people in process within the company that said you still need to choose the right tools and there's a lot of fear and uncertainty and data out there as to which tools to use and I think there's a lot of misrepresentation of tools in the marketplace before I go into the specific tools let's just talk about why I so initiatives actually need a technology investment so it's really really difficult to control people and to communicate a process without some medium to reach those people and a way to actually communicate that process so I think that whatever technology investments are made need to be looked at in that light they need to be tools that help you manage people and change and communicate processes within the organization the second thing is is the tools need to help you measure your return on investment when you go into nazar a project you're probably going to have to justify your own existence and establish some sort of criteria by which you're going to measure the success of this initiative at the end of a year or two years or six months so the tools that you choose need to be able to actually provide that miserable return on investment the tools also need to be able to automate and ordered the governance processes that you put in place I'll talk a little bit about automation later on when I talk about integrating automate but essentially automation actually adds to the return on investment and lowers the total cost of ownership of its away it simplifies the development processes that you put in place and it actually offers a carrot back to the organization as to why you need to make a tool investment in the first place when you look at tools you need to look at the entire lifecycle planning development and operational aspects all need to be considered and they all need different tools and as I mentioned I'll also get to this later on when I talk about the entire lifecycle the danger that exists is they're choosing the wrong tools or having the wrong focus can really put an organization down a rat hole you can spend a lot of time analyzing a tool or spending a lot of time trying to get that square peg to fit in that round hole to implement whatever development processes and governance processes you want to put into place it's really important that you choose the right tool that's it common mistakes are building a bunch of services so if you think about my last slide where some SOA governance projects or initiatives are driven by development in many cases what happens is a service gets both for a services sake it's not both with some induce in mind or consumer in mind so in many cases many failures can be related to just building a bunch of services that nobody uses at the end of the day another common mistake is looking at the architecture as a homogenous entity as opposed to heterogeneous entity most of our customers are heterogeneous they have multiple platforms multiple esps multiple BPM tools multiple development environments so the SOA problem as a whole is a heterogeneous one if you tackle a particular line of business or a particular development organization the danger is that you would tackle it with a single technology in mind and the processes and practices you put into place will not apply to other technologies within the organization and that's the danger as well the other danger is forcing consolidation and standardization using an ESB I believe that an ESB is a bit of a misnomer in that it is not an enterprise service bus it's very very difficult to consolidate and standardize on a single ESB within an organization simply because organizations are heterogeneous and every single platform vendor offers their own ESB so just by the general nature of developers and the general nature of organizations you will end up with more than one ESB so instead of trying to force everyone to consolidate and standardize on a single ESB which will be very difficult to manage and very difficult to gain consensus for a better approach is just to let everyone have their own ESB and ensure that you can govern them all evenly the last common mistake we find is that registries and repositories have a special purpose and a particular target audience it's very very difficult to implement a runtime registry and get a development team to use it or get a operations person to leverage a development repository it is not a case of one-size-fits-all you have to look at the life cycle you have to look at the people that are using the tools and I'll talk about that a little bit more later on

One Comment

  1. Adriano Malaquias
    Adriano Malaquias July 20, 2019

    Great video. Thanks

Leave a Reply

Your email address will not be published. Required fields are marked *