Coffeehouse Thread

20 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Selling WCF/SOA

Back to Forum: Coffeehouse
  • User profile image
    spivonious

    Our current systems are written in primarily VB6 in a client-server architecture. Database access is somewhat centralized in an ActiveX DLL, but there is no coding standard that mandates this, so some clients may still roll their own DAL. Updates to apps are performed with a custom-built ClickOnce-like process. Remote users are handled with remote VDI and Citrix.

    How would you sell SOA to management?

  • User profile image
    vesuvius

    This is quite a complicated question, with a number of unknowns but I will try anyway, I can always be corrected.

    My first selling point is why this would be attractive to them as a proposition. Is this going to save them money, how much and when will they notice?

    How many man years have gone into creating the system, and though painful at times, the system is stable, profitable though lacking robustness.

    Service orientation is quite costly to develop and maintain. Any multi tier application requires changes in various tiers for new functionality to be added and there is no silver bullet, and who knows if RIA services will be available for fat clients as no announcements have been made thus far - it may not even fit your business.

    I don't think you will ever have a meeting with the "Gaffers" one day, and the next start re-writing everything. For me, the best thing to so do some sums and present them with a cost benefit breakdown (99% of the battle here) and possibly target a client or two that can use Service Orientation, build the services and infrastructure and present both to the bigwigs.

  • User profile image
    W3bbo

    ,spivonious wrote

    Our current systems are written in primarily VB6 in a client-server architecture. Database access is somewhat centralized in an ActiveX DLL, but there is no coding standard that mandates this, so some clients may still roll their own DAL. Updates to apps are performed with a custom-built ClickOnce-like process. Remote users are handled with remote VDI and Citrix.

    How would you sell SOA to management?

    I wouldn't advocate using SOA (and WCF in general) for implementing a data access layer or solution, it's just asking for trouble. Remember that SOA is about providing services to clients, which implies a small, manageable set of operations that actually do stuff rather than simply interact with data.

    I'm working on a RESTful SOA right now, and it exposes operations such that clients don't need access to the raw data.

    Your situation does sound like a bit of a mess, but I don't see how SOA (or a central DAL) fixes any problems.

  • User profile image
    vesuvius

    @W3bbo: It gets rid of two data access methods i.e. the ActiveX.dll method and the Citrix virtualised method. All clients remote or not access data in the same way (and same application), that is half the test matrix, and by the sound of it, forces everyone to be on the same version. the software immediately becomes less messy, as updates can be rolled out once, but I don't know the specifics of the business, this chaos could be organised.

  • User profile image
    spivonious

    The benefits I see in going to an SOA are:

    1. Devs no longer have to keep track of where things are in the DB. The DB has evolved over the past ten years and is quite the mix of styles and naming systems. With SOA they can just say "Get me the groups with these IDs" instead of constructing a parameterized SQL query. It would also let us smoothly move away from legacy ADO and onto more modern (and better performing) data access technologies.

    2. Users would no longer need the Oracle client software. This would let us upgrade versions of the client easily and take advantage of connection pooling.

    3. Future applications could be written to access this data without being inside of the local network. Smartphone apps, web sites, smart client apps, etc. Users wouldn't have to remote in just to check some results; they could run a local app on their home PC that would get it all over the web.

    4. Common data access and business logic code could be consolidated and shared across applications.

    And these are just off the top of my head. I'm sure more benefits would come out of it. The problem is that our current system works and management is very reluctant to change if things aren't broken. Case in point: we're still on a mix of Office 97 and 2003, and Windows 2000 and Windows XP.

    @Vesuvius - the current system was put into production about ten years ago and has had pieces tacked on ever since. Our team was three people back then, and is now eight. Most existing applications are extremely fragile. Adding a new field to the database usually means code changes to 4-5 applications.

    edit: Many of these benefits would also come with simply moving to a three-tier system. Am I correct is thinking that WCF is the best choice?

  • User profile image
    aL_

    Only having data access in one place will reduce testing and maintenence effort.

    However, refactoring software into "services" can take a lot of effort, but you can usually do it in stages, basically defining a service that will serve the needs of multiple other components and then replacing the code in those components with the calls to the service, usually removing a truckload of code in the process.

    Also, what actually constitutes a "service" really depends. Does it make sense to have all the data access in a single service? it might if the data access is not extensible, but if it is, perhaps multiple services are needed.

    Really, what we're talking about is decoupling systems, reducing code repetition and increasing composability to a degree(since services will tend to be general), all things that i really think is universally accepted as good.

    Imo SOA doesnt imply wcf, ws* or even network access at all, to me something like an IoC is the very essence of a Soa design. You define abstract contracts for "things" and then use those contracts where ever possible.

    A decoupled system will be easier to test and easier to maintain. It will be easier to devide efforts in a larger team and easier to reason about and document.

  • User profile image
    aL_

    @spivonious:

    wcf is very nice because its transparent to the transport used. apps can change from using web services, .net tcp, msmq or shared memory with no changes to the actual code.

    as for motivating management, how about cost? software licences, maintence costs for updating all clients instead of just a single server, just to name a few Smiley

  • User profile image
    kettch

    @spivonious: It sounds like you've got a pretty good handle on the benefits that the developers would see. Now you just have to do what vesuvius said and put it in terms that the bean counters can comprehend: Time and money. Since time==money, you'd think you'd just have to put dollar values on things, but sometimes accountants calculate time different than normal people. So, I'd still figure out the time involved.

    Don't just go off the top of your head. If management doesn't want to change stuff that "works" you'll need to have a big list of everything you can possibly come up with.

    One benefit is that with a simplified architecture it will be easier to train new employees and move people between work items without onerous amounts of catch-up work.

    Whether or not WCF is the best choice is going to depend on who consumes the services. If they are capable of making the leap, then go for it. Otherwise, you might have to start work on the back end and eventually move the changes higher up. Where I work, we have a legacy application that we are moving to modern technologies (SQL Server, WCF, Silverlight, etc) from an aging Oracle database and Cold Fusion. In this case we are starting deep in the back end. We'll be redesigning the database and providing services that provide all of the necessary operations. The short term goal is to make just enough changes to the legacy system to allow it to use the new services via some fancy footwork and shims. Making those changes to the old system might seem like a waste of time, but we're confident that we can increase the stability and performance just by replacing those components. There are several agile sprints that are aimed specifically at providing real benefits even though the full project might be a long way from completion.

    You'll want to make sure that all of the developers are on board. One carmudgeony senior developer can kill the whole project. Is the immediate superior to the developers on board? You might also want to find a champion outside of that core group of people. It can be one person from management, from another department, or a customer. If you can find somebody who might be convinced of the tangible benefits that you can provide, then that person can advocate for you.

  • User profile image
    vesuvius

    @spivonious:

    1) Good but not really convincing, your service layer can get just as messsy, what design patterns are you going to use? This isn't really saving me money, and the applications cannot be that slow at present. If it was, something would have been done about it by now

    2) How much money and hassle does this save?

    3) Halcyon dream? Have you any business cases that illustrate a requirement for this at present?

    4) Very nice, but I am a manager, the most important thing to me is money, I am a greedy so and so as well. Thus far you have not shown me how this will save me money. If you had come in and said I will reduce the software team from 8 to 4 in 6 months and still be as functional I might start paying attention

    Not being devils advocate,

    WCF seems perfect for what you require. It is hard to learn, but I cannot think of a bad thing to say about it. I have some critical systems using it and it rocks

    Also, can you try and divide you proposal into distinct phases because this will be a long project, and you may need to bring in expertise to preclude the same mistakes where you database has a mish-mash of styles. You will also need to include things like scalability, server upgrades, licenses and so on, this is not a small task so you are starting to playing a game betweel 0 and 100 at -100. 

  • User profile image
    MasterPi

    Mention training cost reduction. How many training hours (st. hour == $) are saved for new devs?

  • User profile image
    kettch

    ,vesuvius wrote

    Also, can you try and divide your proposal into distinct phases...

    This.

    It's kind of a catch-22, but you'll want to have the plan thought out enough that you can convice management to let you proceed with the real planning, but not so much that they ask why you've been spending so much time on unsanctioned projects.

     

  • User profile image
    spivonious

    @Vesuvius - nice reply from management's perspective.

    1. The apps are slow, but people have been dealing with it for ten years, so I think a lot of them don't realize that it could be faster.
    2. Does it save money and hassle? Definitely on the developer side, once the transition is completed. I can see it allowing us to get to more work orders and provide a faster turnaround time on releases. But how do I show this? I can't just make up numbers.
    3. I had to look up the Halycon dream phrase. Must be more British? There is no immediate business requirement for moving to SOA. It is just wishful thinking at this stage. Other devs on the team aren't as motivated to keep themselves up-to-date on technologies. Some of the older ones are even fine sticking with a functional model in VB6.
    4. The company has never laid off anyone in its 50 year history, so cutting the size of the dev team is not a concern of theirs (and could even be a negative). It would let us work faster and with fewer mistakes, as code wouldn't be as duplicated.

    Dividing it into phases definitely makes sense. I think the first step would be to replicate our DAL library in a service format so we could get the centralized data access logic right away, and then upgrade apps as they need other changes.

    Once the apps are fully converted, then we could move on to normalizing the database and cleaning it up.

    @MasterPie - we haven't hired a new dev since myself five years ago. We've interviewed a ton, but they usually aren't skilled enough or want too much money. So in that respect, our training costs are zero.

    @kettch - I just thought of all this yesterday as I was playing around with WCF. There is one curmudgeony (that's a great word) developer who is very resistant to change. We did manage to get her on VB.NET, but she still programs in her old functional style, throwing everything into the Form classes and event handlers. Maintaining her code is a nightmare.

  • User profile image
    figuerres

    ,spivonious wrote

    @Vesuvius - nice reply from management's perspective.

    1. The apps are slow, but people have been dealing with it for ten years, so I think a lot of them don't realize that it could be faster.
    2. Does it save money and hassle? Definitely on the developer side, once the transition is completed. I can see it allowing us to get to more work orders and provide a faster turnaround time on releases. But how do I show this? I can't just make up numbers.
    3. I had to look up the Halycon dream phrase. Must be more British? There is no immediate business requirement for moving to SOA. It is just wishful thinking at this stage. Other devs on the team aren't as motivated to keep themselves up-to-date on technologies. Some of the older ones are even fine sticking with a functional model in VB6.
    4. The company has never laid off anyone in its 50 year history, so cutting the size of the dev team is not a concern of theirs (and could even be a negative). It would let us work faster and with fewer mistakes, as code wouldn't be as duplicated.

    Dividing it into phases definitely makes sense. I think the first step would be to replicate our DAL library in a service format so we could get the centralized data access logic right away, and then upgrade apps as they need other changes.

    Once the apps are fully converted, then we could move on to normalizing the database and cleaning it up.

    @MasterPie - we haven't hired a new dev since myself five years ago. We've interviewed a ton, but they usually aren't skilled enough or want too much money. So in that respect, our training costs are zero.

    @kettch - I just thought of all this yesterday as I was playing around with WCF. There is one curmudgeony (that's a great word) developer who is very resistant to change. We did manage to get her on VB.NET, but she still programs in her old functional style, throwing everything into the Form classes and event handlers. Maintaining her code is a nightmare.

    a few things that you may or may not have in mind just yet:

    1) using WCF or any of the "SOA" models means that you may need to re-think how to do the client server layer, in some places you may want to get a chunk of data back in one call to keep from making way to many network round trips.

    2) keep in mind that WCF let's you expose the same service logic over different channels for example asmx to some clients like a web browser or a linux box but tcp/ip sockets for internal connections and vpn's

    3) seperation of concern :  up front some of the re-desing / transition will cost in time and $$ but one of the paybacks is that you can keep some devs focused on the SOA end of the system and others on the client and UI areas of stuff and reduce the issues of one developer having to try and understand all of the system.

    4) SOA and SOC together should lead to a place where new things can be built w/o having to touch other code,  a new app should be able to run along side old code and other apps w/o breaking them.

    5) versioning SOA :  have a plan for how to update a service method such that you are not breaking clients using V1 of the method and how can you take V1 out of service later? when will you know it's safe to retire it?

  • User profile image
    spivonious

    ,figuerres wrote

    *snip*

    a few things that you may or may not have in mind just yet:

    1) using WCF or any of the "SOA" models means that you may need to re-think how to do the client server layer, in some places you may want to get a chunk of data back in one call to keep from making way to many network round trips.

    2) keep in mind that WCF let's you expose the same service logic over different channels for example asmx to some clients like a web browser or a linux box but tcp/ip sockets for internal connections and vpn's

    3) seperation of concern :  up front some of the re-desing / transition will cost in time and $$ but one of the paybacks is that you can keep some devs focused on the SOA end of the system and others on the client and UI areas of stuff and reduce the issues of one developer having to try and understand all of the system.

    4) SOA and SOC together should lead to a place where new things can be built w/o having to touch other code,  a new app should be able to run along side old code and other apps w/o breaking them.

    5) versioning SOA :  have a plan for how to update a service method such that you are not breaking clients using V1 of the method and how can you take V1 out of service later? when will you know it's safe to retire it?

    Thanks for posting.

    1. Good point. I think a lot of our apps currently just get stuff when they need it, without thinking about what may be needed in the future.

    2. That's what I like about WCF - you can tailor the clients to use the optimal transport.

    3. Not something we'd benefit from from a cost standpoint. We tend to have teams of one dev and one tester for a complete app. Other devs are working on other projects. It would result in more easily testable designs, and easier maintenance in the future.

    4. That's a nice benefit that I hadn't thought of.

    5. This is something I need to research. I thought that if the method signature stayed the same it wouldn't be an issue.

  • User profile image
    magicalclick

    It is basically mean "cloud" right? You go bunch of data in the cloud and they have a big ? mark. And you have WCF or SOA communication standard to acess that big ? mark. Since you have a communication stardard, it is a lot easier to build apps on top of it. This basically mean you can have whatever you like in big ? mark and whatever platform you like to access that big ? mark.

    Basically it is an unlocked-cellphone that can have any carrier you like, meaning, the cheapest carrier you like. You can buy any cheap cellphone brand and use any cheap carrier provider. NO CONTRACT. How awsome is that?

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    MasterPi

    ,spivonious wrote

    @MasterPie - we haven't hired a new dev since myself five years ago. We've interviewed a ton, but they usually aren't skilled enough or want too much money. So in that respect, our training costs are zero.

    No skilled enough to develop for/maintain the current system?

    So, basically you would reduce the skill level required for future maintenance.

  • User profile image
    figuerres

    ,spivonious wrote

    *snip*

    Thanks for posting.

    1. Good point. I think a lot of our apps currently just get stuff when they need it, without thinking about what may be needed in the future.

    2. That's what I like about WCF - you can tailor the clients to use the optimal transport.

    3. Not something we'd benefit from from a cost standpoint. We tend to have teams of one dev and one tester for a complete app. Other devs are working on other projects. It would result in more easily testable designs, and easier maintenance in the future.

    4. That's a nice benefit that I hadn't thought of.

    5. This is something I need to research. I thought that if the method signature stayed the same it wouldn't be an issue.

    versioning:

    look at it as you have 3 parts that may or may not need to change:

    the parameters, the results, the logic inside the method.

    if the in and out stay the same then yes you can re-factor / fix / update the internal logic and the clients will generally not need to have any update to use the method.

    but when you need to for example add new result data in some cases the old client can ignore the new data but this depends on the format / structure of the data.

    sometimes i have had to keep two versions of a method so that the clients could migrate.

    for example method GetThisData()  then GetThisData2()

    then publish a client update that the clients now call GetThisData2()

    then later when we know that all of the clients have updated comment out the first method.

    that's how i have done it so far.

    as for #3 you will be doing it as a by product of what a SOA is, the thing is you can look at who is good at what, then put the devs who are really good at the server side code and database stuff on the server side stuff and let the folks who are better at UI and client interaction focus on what they are good at.  that should lead to a $ benefit but not at the start. better application UI better presentation, better work flow.

    Also if you have one set of staff consuming the work of another set then you have another level of testing to make sure stuff is right.  so you should catch and fix things faster before they get to UI testing and my the time the UI testing has been done the server code should have in effect 2 sets of tests to pass.

    That should result in less bugs in a released app.

  • User profile image
    kettch

    @figuerres:I haven't been able to dig too deeply into it lately, but the built-in versioning in WCF looks pretty cool.

    http://msdn.microsoft.com/en-us/library/ms731060.aspx

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.