As Chief Scientist for PRICE Systems, provider of world class cost estimating tools and services, I spend my days researching new technologies, processes and techniques associated with the development and production of hardware, software and systems. While the end goal is to develop an understanding of how various factors impact cost, the journey requires that I learn new things every day about how the world works. I frequently publish or present these findings to the cost and measurement communities in various venues around the world. The primary focus of my research (and my main passion) is all things related to Software Development and Information Technology although this has not precluded occasional forays into topics such as hardware manufacturing, systems engineering and composite materials. The goal of my research is arming cost estimators with the best technology available to address their estimating challenges and help them achieve estimating accuracy. Read more about Arlene Minkiewicz
Well run, tightly scoped projects with little scope creep and excellent project and change management practices are less likely to suffer from the ambiguities outlined above. (How many of us work on one of these every day?) These of course are the projects least likely to run out of control in the first place. The things that make a project risky are the things that make it easier to misread what EVM is telling you, creating an allusion of control for a project which has little. It is unwise to rely on EVM results as the only measure of a project's health, rather, one should heed Millaly's suggestion that blind adherance to earned value could cause your project to crash and burn.
To be honest, when I first wrote the abstract for this talk – I was really looking for a catchy title so the conference reviewers would pick my paper. Not that I didn’t believe that SOA governance was critical, but I knew that all governance was important and it felt a little disingenuous and self serving to just focus on SOA governance.
But as I was presenting this topic, it hit me how critical governance is to a SOA initiative. SOA is successful when the enterprise realizes savings through reused assets and all of the benefits that come with business agility. Without good SOA governance this will only happen in pockets of the organization at best. Organizations that purchase SOA technology and then continue to develop “SOA” in silos – are not realizing these benefits. SOA Governance ensures that decisions on SOA projects are made with knowledge of all of the SOA initiatives in the organization, not just within a certain aspect. It makes sure that projects are coordinating their needs for services and taking advantage of existing services (internal and external) while composing SOA applications.
Alert readers are undoubtedly now lauding me for my flair for the obvious. And you are absolutely correct. All that I said above should be perfectly obvious to anyone involved in or contemplating adventures into the world of SOA. Despite this fact, in our research we have talked to a lot of people who struggle to keep from developing ‘stovepipes of SOA’ and a fair amount who have conceded the battle. Taking this into account along with the fact that I (who thinks about this stuff a lot) needed to be reminded, I figured this was a blog worthy topic.
To learn more about PRICE’s research in the governance area, download the webinar "Estimating the Costs of Service Oriented Architetcure" or read the whitepaper "Estimating SOA".
Joint Confidence Level (JCL), NASA’s current best practice for program planning and management, also presents a circuitous conundrum. When a program has a JCL of 70% this implies that there is a 70% confidence that the cost will be at or under X$ and the program will be completed at or before Y months. Much time and effort has been invested in developing methods for performing JCL using lots of different mathematical and statistical processes. But many of these methods and techniques ignore a rather important aspect of cost and schedule estimating – schedule drives cost and cost drives schedule.
This fact does not make JCL analysis impossible. It merely means that cost and schedule risk analysis cannot be performed in vacuums. Rather than calculating a JCL we should be trying to converge on cost/schedule pairs that meet specific JCL requirements.
Next week I will be attending the 2010 NASA Cost Symposium in Kansas City, MO. Because JCL is such a hot topic with the NASA cost community, nearly half the program, including my own talk, is devoted to this topic. Lots of great work is being done in this areas. I encourage anyone with interest to attend if they can or follow up with conference materials when they become available later this month.
The reason I think it’s important to share this is that so many of us in the cost estimating community rely heavily on expert judgment as a means to perform or validate estimates. On page 48 of the paper a section entitled “Experts have a High Opinion of Their Own Opinions” begins. In this section the authors describe an experiment where researchers took a group of smart people (Harvard Business School students) and asked each to estimate high/low range numerical answers to several questions in such a way that they had a 98 percent chance of being correct and a 2 percent chance of the correct answer falling outside the range they selected. So for example “I am 98% confident that tomorrow’s temperature will be between 50 and 120% F”. There were no limitations on the ranges they could select and yet the students failure rate was close to 45%. Similar studies have had similarly lackluster results. To paraphrase the authors’ conclusions….
“We over-estimate what we really know while underestimating the possibility of our being wrong.”
The author is quick to point out, and I completely agree, that this is not evidence that all expert judgment is not valid, just a warning to those who depend exclusively or significantly on expert judgment. No estimation should be done in a vacuum. The more methods (parametric cost estimation included) used to arrive at an estimate the more credible the estimate and the higher the confidence level in that estimate.
Earlier this week I conducted a webinar intended to make PRICE users aware of the Cost Research Services available to them as part of the license fee they pay to use PRICE products. I thought I would recap the highlights of this webinar for those of you who might have missed it.
At PRICE we understand that cost estimating tools, while useful and valuable, do not always present the complete solution. Every single cost estimation projects presents new and unique challenges. We think it's important that in addition to solid, time trusted cost estimating models, our users have access to the many years of experience we have as seasoned costestimators, subject matter experts and operations researchers.
This service is nothing new. For the 30 years that PRICE has been in existence, we have worked as partners with ourcustomers to optimize their use of our models and methodologies. This was just an opportunity to formalize the offerings and remind the community what services are available.
So what does the Cost Research team at PRICE have to offer the cost estimating commmunity? On average our researchers have more than 24 years of experience with hardware estimating, software estimating, operations research or some combination of the three. We are constantly engaged in cost research projects addressing market needs as they arise. The results of these studies vary depending on the need they attempt to address. In some cases, data collection indicates custom models should be developed. These can be developed and deployed in TruePlanning, the flexible cost estimating framework. Some results are published as updates to tables or calculators in the PRICE Software and Hardware cost estimation models. White papers, webinars and the PRICE blog are all means we use to communicate the results of cost research studies.
PRICE's Cost Research Team is available 24/7 to address users cost estimating question on an as needed basis. Some issues require more attention than a single phone call. Users are encouraged to schedule working sessions with one or more of our analysts to take a deeper dive into cost estimating issues that perplex or intrique them.
Some areas the team is currently studying include Total Ownership Costs, Joint Confidence Level, Performanced based models for technologies such as FPGAs and ASICs, semi-rigid cables, and Operations and Support costs for space systems.
The most important thing the cost research team at PRICE wants to do is make our clients better estimators while adding value to the cost estimating community as a whole. We can't do this without input from our clients. Share your cost estimating challenges with us. Call, email or comment on our blog. 856-608-7201 or info@pricesystems.com
Software project falures coupled with rapidly changing business needs are forcing organizations to revisit the way they go about buiilding software. Agile development has emerged as one possible solution to the woes of the software industry. Agile enthusiasts claim significant increases in productivity and quality, while detractors cite instances where the reverse is true. It seems to me that probably both are right - some of the time anyway.
Agile means many different things to different organization. There is a long list of agile tenets but not every method of agile applies all of them. And some organizations have cultures which adapt well to agile methods while others don't. All of these things affect the 'success' of applying agile practices to your organization.
Personally I don't think that most agile practices inherently improve productivity. The long term application of agile within a cohesive development team should definitely improve their productivity but this would probably be true of the same team if they were applying some other philosophy.
I do, however think there are agile practices specifically focused on improving the quality of the software that is delivered. My list follows.....
Test Driven Development No code is written until there is a test. Business Analyst build tests that coders use to determine if the code meets the requirement. Only enough code is written to make the test pass. As code is refactored (improved) over time, the test remains to ensure that subsequent changes do not degrade the initial requirement.
Continuous Integration and Automated Testing Builds are run with each change to the code base or at regulalry scheduled intervals during the day. Suites of automated tests are run against each build. When tests fail making them pass because a number 1 priority of the test
Pair Programming All production code is written by two coders one at the key board and the other navigating, correcting and thinking of better solutions. Sort of like just in time peer reviews. Pairing occurs regularly throughout the development - with no set pairs but rather pairs that make sense at the moment. Driver and navigator roles should shift often.
Customer involvement Customers (or their surrogates) actually participate on the development team helping the business analysis develop the right tests and testing and reviewing the frequently released versions of the software
While these practices are included as tenets of agile, a shop need not be 'agile' (in the purest sense of the word) in order to incorporate one or more of these quality focused practices into their software development processes.
To read more about Agile practices and software quality check out my article in Software Tech News
Despite the plethora of literature on Technology Readiness Levels (TRLs) it remains a difficult concept. I thought I would share my interpretation,
For most of us the concept of technology readiness is hard to grasp. This is because in general, our experiences with technology are with fully matured technology. In 1961, President Kennedy challenged US scientists, mathematicians and engineers when he announced that within the decade of the 1960s the US would ‘land a man on the Moon, and return him safely to Earth’. At the time, there were no solutions to solve problems such as reaching earth’s orbit and traveling to the moon, let alone for how man would be able to survive in space. Some very smart people and creative thinking was needed to invent solutions that didn’t exist in order to make Kennedy’s dream a reality.
One of the many things that these smart people discovered was that programs envisioned when the technology is very new or non-existent are much harder to plan for than programs using technology that has been used successfully on other programs. As the possibilities for the space program greatly outsized the budget for space programs this fact became increasingly problematic. In 1974 Stan Sadin of NASA developed Technology Readiness Levels as a methodology to assess the technology readiness of a proposed spacecraft design. Eventually the methodology was institutionalized by NASA and later similar methodologies were developed by the US Department of Defense (DoD) and other organizations responsible for the acquisition of complex aerospace and defense programs. TRLs are used by NASA and the Departments of Defense worldwide to support go/no-go decisions at various acquisition milestones.
Here's how I like to simplify TRLs.....
Level 1 => Back of the napkin sketch
Level 2 => Idea confirmed as both good and useful
Level 3 => Idea proven possible
Level 4 => Idea proven to present a realistic solution
Level 5 => Alpha version of technology
Level 6 => Beta version of technology
Level 7 => Release candidiate ready for operational test
Level 8 => Technology has gone gold
Level 9 => Technology used successfully in target environment
Failed software projects are always bad but there are additional complications when there is a contract in place to deliver the software. Disputes over failed software can result in costly litigation that generally damages both the vendor and the buyer. According to observations of Capers Jones in "Conflict and Litigation Between Software Clients and Developers" (2007) , 5% of the projects his clients were involved in either had litigation pending or were currently involved in litigation over project failures. His findings indicate that it is very large projects, over 10,000 Function Points that are most prone to litigation, which makes sense if you consider the relative increased complexity, as well as the large amount of money such a contract would involve. Although one occasionally hears of pending litigation over software projects in the news, determining the background and outcomes of such litigation is difficult because they involve large customers and software contracting organizations, both of whom would rather keep their failures out of the spotlight. This is likely a significant contributor to the fact that such litigations still occur since the industry is denied opportunities to examine and learn from the mistakes of others.
A report in Computer World [6] details a law suit filed by health insurer Highmark against KPGM for malpractice, fraud and brief of contract for a software system that Highmark had outsourced to KPMG. While the article does not detail the outcome of this lawsuit, it makes it clear that the disagreement stemmed from misunderstandings and the failure of the two organizations to communicate and collaborate.
In light of this I have compiled a list of four responsible actions that both bidder and buyer should engage in when software projects are outsourced. These may seem like common sense and the same old story, but clearly they bear repeating......
1. Create and Communicate Good Requirements ... misunderstood, constantly changing and new requirements are a common source of angst in software development projects. Bidders need to understand the buyers requirements, document them fully, and incorporate the risk of requirements growth into their plans
2. Create and Maintain a credible cost estimate - the buyer needs to know what the effort should cost to evalute bids. The bidder needs to properly assess the cost to them in order to make the project profitable and to avoid having the project cost them money
3. Understand and document risks; Plan up front for risk mitigation - bidders should work with buyers to understand their uncertainties. These uncertainties need to be incorporated into the estimate and documented in the contract.
4. Create and maintain a cooperative relationship... when bidders and buyers collaborate and work nicely together, bumps in the road and set backs are handled sensibly, reducing the possiblities that things get out of hand.
Recently I was interviewed by Doug Beizer of Federal Computer Weekly for an article about the shift of government agencies away from custom software development and towards the use of cloud computing. The interest in this topic seemed to stem from the introduction of Apps.gov online store earlier this month.
Having been in the software cost estimation community for more than 25 years, I have experienced this transition first hand but never really stopped to think about the whys and wherefores until questioned by Doug. It was an interesting stroll down memory lane. As an example, just think for a minute about how much communication has changed. When Ifirst started working if I needed to discuss something with a co-worker or friend I either needed to pick up the phone or pick myself up out of my chair and go talk to them. If I wanted to leave a paper trail – I actuallyneeded to use paper. There was no internet, no e-mail, and certainly no social networking. Like everyone else,government agencies needed to develop custom application to meet specific communication, networking and other needs. Because the government had many communication needs – both on the business and mission side – government agencies became a leader in developing these types of applications.
With the advent of the Internet and ever evolving forms of social networking, the commercial sector has been forced to get really good at developing communication software – so good that the government agencies are nowl ooking more and more to the commercial sector and the cloud for such capabilities. Not to say that all government needs can be solved with commercial solutions, but many more so than back in the day. And while communication capabilities are my favorite example, let’s face the fact that there’s a lot of software out there– many of it that’s completely adequate (if not superior) to meet the needs of the government.
A part of my job at PRICE is to look into emerging trends and technologies to determine if and how changes in the world impact the costs of hardware, software and information technology projects. An area of great interest to me is the greening of IT. I am interested in this for several reasons. First of all I care about the world and worry about the environmental situation we are leaving behind for our children. Secondly I think that Green IT is a win-win for businesses.
In an article in last weeks Harvard Business , IT Costs: Do You Speak Their Language), John Sviokla discusses the fact that as the information business continues to grow it is increasingly important for organizations to understand the impact of IT as it relates to their operating costs. This certainly rings True to us here at PRICE Systems who have recognized this reality. TruePlanning 2009 has been developed by PRICE specifically to help organizations get their heads around the true costs of Information Technology.
Application development projects can represent significant expense to an organization and tend to be the riskier items in the IT budgets. But it is important to recognize that they represent only a small part of most organizations IT budgets. According to Gartner’s "IT Spending and Staffing Report 2008",on average organizations spend about 20% of their IT budgets on application development. The rest of their budget is spent on hardware, software, networking, maintenance, as well as data center and help desk activities. The figure below indicates the typical distribution of IT costs based on this report:
From this last report we see that over the last 7 years the distribution of investment dollars between on-going operation and growth and innovation has remained steady with operational expenditures dominating. On average, organizations have spent 65% of their budgets to run the business, 21% to grow the business with a mere 14% of the budget left to transform the business.
With technologies such as SaaS and cloud computing, there is potential for organizations to make decisions to change this picture but they first need a way of identifying what in their IT organization is driving operational costs. TruePlanning for Information Technology makes it possible to model both your appliation development projects and the IT infrastructure (at a micro or macro leve) to help identify the best choices for optimizing Information Technology
Bad project estimates lower profitability. Despite this fact many business leaders don’t invest in improving their estimating capability, buying into the fatalistic myth that this is as good as it gets. This is patently wrong. Project portfolios are prioritized based on the total expected Return on Investment (ROI) of projects. Investments in the wrong project based on bad estimates could lead to lost revenue or delay of net benefit.
All around us we see reports of software projects which are over budget, delivered late or cancelled because they are taking too much time and money. This very fact makes it easier for business leaders to throw up their hands and accept bad estimates instead of proactively looking to improve their estimating capability and their profitability. It doesn’t have to be this way. Any organization can turn this around with careful analysis of their own history combined with analysis of relevant industry benchmarks. TruePlanning by PRICE Systems contains the methodology and cost estimating software to help business leaders utilize history to improve project planning and avoid making bad decisions.
It's finally Spring! And along with the leaves on the trees, the beautiful flowers and the happy chirping birds.... it is once again Baseball Season. Baseball season is a beautiful thing - and not just because, as a resident of South Jersey, my team is the 2008 World Champion Phillies. I just love the game and everything about it. I believe this is because with baseball the impossible becomes possible because anything can (and will) happen and with a good plan in place you can still be successful.
I didn't always love baseball. When I was a kid growing up in Baltimore - my Dad - a huge baseball fan - would take our family to Memorial Stadium to watch our beloved Orioles play. It was fun for the first few innings but after the hot dogs, sodas and peanuts were finished - it started to get a little boring (Sorry Dad but I just didn't get it). Years later, as the mother of young little leaguers I actually detested baseball. The only things worse than spending all your evenings at the little league field watching bad pitchers (cause they were learning) throw balls to bad batters (who were also learning) was the drive home with aforementioned (now angry) bad pitchers and/or hitters. But as my boys matured something miraculous happened. The kids started to play well and I started to enjoy the games. The more enjoyable the games were the more I cared about the rules, the nuances, and the numbers of baseball. Only after this journey did I realize what a great game baseball is. A good team with good players, passion and a coach with a good plan can turn almost certain defeat into victory.
Project Planning is not all that different. When starting a software development project you need to start off with a plan and then you need to recognize that absolutely anything can happen. Like a good coach you need to understand your risks - and you need to have contingency plans in case something unexpected happens. A tool like PRICE Systems TruePlanning for IT is a good place to start. TruePlanning not only supplies cost and effort estimates based on descriptions of your project and your team, but it lets you indicate the uncertainty in these descriptions to add a level of confidence to the plan produced.
I have to say that my foray into blogging has been an interesting one. By definition, the Chief Scientist should be a nerdy sort of geek too high brow to pontificate on topics in such a pedestrian format. Actually I kind of like it. In part because I enjoy writing and I'm not picky about what I write - technical documents are OK but pontification works as well. And in part because I know that in order to be a good writer in a particular genre one must read extensively from that genre. In other words I now have a good excuse to surf the web for related blogs and have found great ideas that have fueled my imagination
Today I want to share an article I found on 'Quips On Software Development' by David Longstreet called "Ancient Wisdom for Software Estimating". In it Longstreet traces the need for good estmating all the way back to the Bible. From Luke 14:25-33 Jesus says to the crowd of discipleship "Which of you wishing to construct a tower does not first sit down and calculate the cost to see if there is enough for its completion? Otherwise after laying the foundation and finding himself unable to finish the work the onlookers should laugh at him and say, 'This one began to build but did not have the resources to finish'"
Of course this was posted on April 1st so my first thought was of practical jokes. After thinking about how cool it would be to get this kind of powerful buy-in on the importance of estimating I figured I would check it out. So I powered up another browser and went to Bible.com (who knew!). Sure enough it was the real deal.
So what's my point here? Regardless of your religious beliefs - it seems prophetic that a document representing life and times more than 2000 years ago recognizes the importance of estimation and resource management. And further acknowledges the fact that people will notice if you say you're going to do something and then don't finish it because you've run out of time or money. Even before there were machines or factories, computers or software; before the words process improvement had ever been uttered - people understood that estimation was important when embarking on a project.
The next time you think about starting a project with a WAG (Wild A** Guess) or with the number your boss wants to hear - first stop and ask yourself... "What Would Jesus Do?"
Here’s a great article I happened upon while doing research for a paper I’m writing. “Lessons Learned: IT’s Biggest Project Failures” In this article we are treated to stories of IT projects that “first make people laugh and then” (hopefully) “make them think.” As a long time student of the failed software project, I was neither surprise nor disappointed with the projects relayed. The projects noted failed for reasons such as:
- Failure to perform a should-cost analysis before selecting a supplier
- Failure to recognize an unhealthy project before it was too late
- Unrealistic and aggressive timelines
- Scope creep.
The US Department of Defense (DOD) continues to be plagued with cost overruns on major weapons systems. Last month Senators Carl Levin (D-Mich) and John McCain (R-Ariz) introduced the 2009 Weapon Systems Acquisition Reform Act intended to put measures in place to force the DOD to address the issues that cause overruns and schedule slippage. Among other things, this legislation would create the position of Director of Independent cost assessment for Major Defense Acquisition Programs (MDAPs) and require the DOD to perform trade-offs between cost, schedule and performance early in the program lifecycle. Read more about this legislation
The DOD's experience with cost overruns and schedule slippage is certainly not unique to them. The size and complexity of the problems that they are trying to solve, along with the fact that their projects are funded with US tax dollars, makes their contract difficulties more dramatic and more public. Everyone who builds large systems knows that the bigger their system the more risk there is that things will change between the time the project is first estimated and the time it is delivered. And most changes that occur within a project involve adding requirements rather than removing them. This is why cost, schedule and performance tradeoffs are so important – early and often in every project.
And while there is no silver bullet that will solve the problems that the DOD and many other systems developers have with projects failing to meet goals – there are tools and methodologies that will facilitate success with cost, schedule and performance tradeoffs. TruePlanning for Products from PRICE Systems provides a framework in which systems developers can translate their own past performance to provide forward looking analyses that facilitate trade-offs between cost, performance and schedule. TruePlanning provides a trade space to help project managers create realistic expecatations for the cost and schedule of complex systems.
Last week I was asked to participate in Career Day at my son’s elementary school. I was both honored and humbled. Honored because the school felt that my career was something the children would be interested in and humbled because I was forced to concoct a story that would make cost estimating and analysis both understandable and interesting to children from kindergarten through grade eight. Fortunately the format was such that I presented to each grade individually so at least I did not have to come up with one story to address all ages.
The experience turned out to be a lot more fun than I imagined. It’s amazing how many kindergarteners in my son’s school have parents that are scientists (although to be fair their teacher informed me that thirty minutes earlier, when a policeman visited the classroom, many of their dad’s were also on the police force). Lots of forensic scientists I suppose!
And it wasn’t really as hard as I expected, explaining what PRICE Systems does. I used images of the kinds of hardware and systems that TruePlanning for Products can be used to estimate. While some of the younger ones thought that I actually had flown on the Space Shuttle, the upper grades got it. The experience actually helped me learn several new things about my job. First of all, I learned that what I do actually is interesting to kids who are starting to think about what they might want to do with their lives. The little kids were fun but the older kids were attentive and asked good questions. The fact that my work contains elements of science and technology exploration, with math and a little bit of detective work thrown in was actually appealing to many of them. I was also reminded of how much I like my job and why. Not only does my job create lots of new and interesting challenges, it also gives me opportunities daily to help people who do software project estimating, hardware project estimating and system level estimating. I get to help these people be more successful at their jobs by providing tools and methodologies that make their estimates credible and believable.
Like many others, I was astonished last Thursday by the images on my browser of those 155 extremely lucky people standing in the Hudson River. And they certainly were very lucky last Thursday. If you’re destined to fly on a flight bound for collision with birds, you want it to be piloted by a hero like Captain Sullenberger. The incident made me think about what a hero is and how we all have the opportunities to be heroic in our chosen professions.
According to Wikipedia, a hero refers to a character that, in the face of danger and adversity or from a position of weakness, displays courage and the will for self sacrifice. As a project manager you may not encounter danger daily, at least of a physical nature, but you certainly deal with adversity on many levels. And courage is essential!
An heroic project manager is one who makes project decisions based on facts and who stands behind those decisions. He or she defends the project team from those who wish to impose unrealistic deadlines and stands up to those who want to abuse or ignore the Project Management Triangle. In order to be heroic, a project manager needs to have the tools necessary to plan a project right the first time as well as manage it with agility as situations change. TruePlanning from PRICE Systems is just such a tool. TruePlanning is the worlds leading solution for software cost estimation and IT Project Planning. It gives project mangers the cost estimates they need to plan projects successfully and the courage necessary to defend those numbers to the naysayers.
Although the use of TruePlanning is unlikely to lead to instant fame or enable people to walk on water, a project manager who uses it regularly will be a hero to the team!
A recent Gartner report indicates that industry enthusiasm for SOA is waning. 
The reasons cited are the lack of enough people with the proper skill sets to perform SOA deployments and the lack of a good business case for SOA. It’s an interesting but not really unexpected direction. SOA has been surrounded by significant hype, ensuring that organizations surveyed would be anxious to profess their desire to start a SOA project. But as the rubber hits the road, these organizations are realizing that SOA may not be the answer to all of their organizational woes.
Many will argue that SOA is nothing new – but rather a repackaging of an object oriented approach to software reuse. They insist that the reason for this repackaging is motivated by a strong marketing push to sell a new generation of tools to folks that were not successful achieving reuse with earlier versions of tools. Although I agree that the notion of SOA is not new, I do believe that technology has been advanced to a level where enough abstraction can be applied to the process to make reuse a possibility. I do agree with the cynics that the heavy marketing push for SOA has not helped businesses make thoughtful decisions about whether it is right for them.
Now that enthusiasm has been tempered, organizations are starting to look at the costs, benefits and ROI of SOA. This is a good thing. A more thoughtful approach across the industry will balance the effects of aggressive marketing and ensure that the right SOA projects are attempted. Of course, the challenge of determining ROI is daunting, particularly without a lot of data. Determining the benefits of a relatively untested paradigm is problematic. If the SOA vendors are to be believed the benefits are tremendous. Experience of course tells us that this is optimistic. But common sense indicates that there is a great deal of potential for benefit for businesses that meet one or more of the criteria listed in the article “Your SOA needs a business case” – in other words if your business must respond to frequent changes in the marketplace or with business rules and relationships.
Understanding, or predicting, the benefits SOA will bring to the organization is only half the challenge. The costs associated with a deployment of capabilities in a service based framework are also an important consideration. The TruePlanning Suite, available from PRICE Systems, can help in this area. TruePlanning allows for IT Project cost estimation that will help address costs associated with deploying the right infrastructure for SOA, the costs associated with development of services, and the costs associated with the composition of applications using services.
Powered by Compendium Blogware