This week HP made a number of announcements around their SOA governance capabilities including new professional services and software in order to help companies “accelerate SOA adoption, drive increased business value and reduce potential risk to the business.”

According to Avrami Tzur, VP SOA, HP’s customers were asking for help in determining the governance process and deciding whether to focus on quality or performance. In response HP has launched three new professional services, all of which are short in length, with defined deliverables. The SOA Validation service comes with Systinet and the best practice governance process for validating services embedded in it. This can then can be expanded across the organization. The Quality service includes pre-defined metrics and processes. Because so many customers already have the Mercury quality software this service focuses on validating the quality and performance. The other new service regards helping customers with performance of their SOA services.

The software announcements include a new release of Systinet SOA Manager. This includes the Talking Blocks software purchased by HP 3-4 years ago. It includes runtime management, security, and routing mediation of web services. HP’s vision is to provide software to govern the whole life cycle of a service.

HP also announces a new product. HP SOA Registry Foundation packages and simplifies the Systinet registry, so it can now ship to many OEMs. It can easily be put on developers’ desks, and into distributed replicated environments such as oil and gas. The US Army is putting it in tanks. The registry is autonomous but is also integrated with Systinet and supports interoperability at runtime to achieve the full governance solution.

HP is also offering a new suite of SOA education and training courses. Last May HP announced its SOA strategy as focusing on governance and management - two areas where HP has considerable enterprise experience and software offerings. HP's strategy is to remain platform agnostic and provide the services and software to manage, govern and provide quality assurance for services. This announcement of new services and software furthers this vision.

Posted by bethgb in Industry News • SOA • Vendor Briefings | Permalink | Comments (0) | TrackBacks (0)

Today Amberpoint released the results of a survey designed to determine the maturity level of the SOA market, the issues practitioners are worrying about, and to assess complexity and technology of their environments. There were a total of 330 respondents, including 48 customers and 282 non-customers. 34% of the respondents were in operations, 31% were in development, 24% were architects, with remaining 11% characterized as "other".

Like all of the ebizQ polls and surveys have shown, the Amberpoint survey found that the majority is still in the early stages of adoption. But there were also some surprising results. The Amberpoint survey showed that relatively few (20%) of the deployed SOA solutions are standalone, single department systems. Most are used across departments or even externally. This survey indicated that the biggest benefit of SOA is its used in addressing integration issues. This, again, is an indication of the early stages of the market as few companies have mastered the art of building reusable business services and achieving true business agility based on SOA infrastructures.

But IMHO the singularly most surprising finding of this survey is that 98.5% of respondents called their SOA implementations "successful". When in the industry have we EVER seen a 98.% success rate with any technology or approach - especially in an early market? I think this is something worth exploring more. What has been your experience. Have you had a 98.% success rate?

Download a copy of the survey results.

Listen to the podcast with Ed Horst, VP Marketing, Amberpoint  

Download file

Posted by bethgb in Industry News • Industry Trends • SOA | Permalink | Comments (1) | TrackBacks (0)

At the end of this month on Jan 30th, I'm heading out to San Francisco for a new conference The Open Group is launching - the IT Specialist Conference. It will be held on the last day of the The 17th Enterprise Architecture Practitioners Conference which runs January 28-30. Both are at the Fairmont Hotel, San Francisco. If you plan to be out there and would like to meet for a chat please respond to this blog. I'll be speaking on a panel and doing some podcasting from out there.

This week I spoke with James de Raeve, VP of Certification for The Open Group. The Open Group is kicking off its IT Specialist Certification program to attendees at the conference along with current Open Group members. We talked about the role of the IT Specialist, and the new certification program.

You can listen to the Podcast here:

Listen to the entire podcast Download file

You can also read the transcript of the podcast.

Posted by bethgb in Industry News • Podcast • SOA Design | Permalink | Comments (0) | TrackBacks (0)

In this podcast I spoke with Dr. Adam Dr. Adam Kolawa, CEO of Parasoft, and author of "Automated Defect Prevention," published in 2007 by Wiley-Interscience. The basic premise is that when you invest in preventing defects in software through infrastructure, automation, and changing the culture of how developers work, the payoff is as much as a 10 fold increase in productivity. Can you afford not to listen to this podcast? Transcript below.

Download file

BGB: Welcome, everyone to this ebizQ podcast. I’m Beth Gold-Bernstein, VP of the ebizQ Training Center and today I’m speaking with Dr. Adam Kolawa, CEO of Parasoft. Dr. Kolawa has recently published a book, Automated Defect Prevention, and it is fascinating. Best practices in software management. And he’s here to tell us about that today. Welcome, Adam!

AK: Thank you very much. I’m very glad to be here.

BGB: And this is really fascinating stuff. You’ve written a textbook here and after this, I’ll tell people how to order the book. I think it’s really a must-read for those in software development. So, let’s start off. Can you tell us about the principles of automated defect prevention?

AK: Sure. So, you know, we were thinking about a way to really help people to improve how the software is really being written. And if you really look at how software is written nowadays, it kind of is very similar to how we manufacture physical goods about 100 years ago. So what we are trying to do in this book, me and my co-author, Dorota [Huizinga], is we are trying to actually help people to elevate the process of software development to the industrial age and really make it controlled, predictable. So we can actually repeat our successes and don’t repeat our failures.

Now, we built this around a theory. And the theory is really automated defect prevention. And automated defect prevention basically consists of three things: which is principles, practices and policies. Principles are the rules, that if you break them, then for sure this whole thing is not going to work. Practices is, what do you do to the software to make it better? So they always refer to the software or to the code or to requirement management, so anything which is related to the software. Policies is, related to how people operate. How do you guide people to actually execute these practices and deliver software?

Now, principles. Basically, we have six principles. And we try to design this whole thing that it fits to any software development process. So we are not trying to create new software development process. We are not embracing any of the software development processes. We are trying to improve what people have.

And now, if you look at our principles, the first principle is basically: you’ve got to have an infrastructure. And this might sound like trivial, but it’s very interesting that a lot of people right now in the industry don’t have the infrastructure to actually build the software. So what do we mean by infrastructure? Well, first of all you need to have a source control system. Most of the people have source control system. You need to have automatic build. Well, maybe 40 to 50 percent has automatic builds now. So this is still a long way to go. You’ve got to have requirement management system. About 80 percent of the industry does not have requirement management system. You’ve got to have regression test suite. Well, most of the people don’t have automated regression test suites, which is really scary. And you need to have something which is going to actually monitor this integrated infrastructure. That’s the principle, no. 1.

BGB: Can I ask you a question about that principle?

AK: Sure!

BGB: I mean, I think you’re absolutely right. IT is like the shoemaker’s children. We don’t necessarily build the tools for ourselves that we’re creating for the rest of the business. And, matter of fact, I’ve heard from managers that they don’t want to invest in infrastructure unless it is delivering customer or business functionality.

AK: Right!

BGB: And that seems to me to be penny-wise and pound-foolish. Because if you have the infrastructure to prevent defection, you will ultimately – it seems to me – save money down the road.

AK: Right.

BGB: Do you have any figures or case studies to show that?

AK: Yeah, we do. I mean, we – in the book – have multiple case studies but what we found, to our amazement actually, and you know, basically what we wrote in this book is what I’ve been living for the past fifteen years and what I used to really run Parasoft. And what we found is that automated defect prevention and infrastructure is part of it, can improve productivity and it can improve productivity by a factor of ten.

BGB: Wow.

AK: So this is a huge number. Okay. So you have infrastructure. Then, you know, actually the next principle which I normally talk about is principle No. 5, which is automation. Now, what I’m talking about, an automated process that delivers the information to everybody who works on the software about how to work on the software, what is the next step to do to that software. So what do I mean? Well, the example of this is, we call this actually an automated build, right? An automated build is that you take code out of your source control system, you rebuild it totally. This is not incremental build, a continuous build is the clean build. And then, the moment you finish building it, you perform static analysis, unit testing and functioning testing on this ___ (6:38) and at the same time, you measure the results of it and you use this to indicate for people what to do next.

So, if you have problems building you inform people of problems of building. You have compiler warnings. You tell them about compiler warnings. You will regression test which detects any change. You distribute the change to whoever is responsible for the change, and they keep maintaining work on the system. Okay?

Now this also, this automation, is basically a backbone of what other principles are doing for the system, okay? So then we have a next principle which is principle No. 4. And principle No. 4 says: Whatever you do, you’ve got to measure and track it. So, this automated process provides you information how much code is being written, is this code being compiled and built? Does it adhere to your standards? Are you really adhering to your policies? And now, you see with SOA and, with SOA, very, very important thing is actually governance.

So, are you adhering to SOA governance? Are you building your Web services in such a way that they can be reused and then, when you modify them, you are not going to affect adversely all of your consumers. Then, are you really modifying your software in such a way that you are not breaking it? One of the biggest problems and when productivity goes to drain is when people modify their software, and they introduce the errors and they track these errors, and there’s this sudden sink of time. So, what you are trying to do, is you are trying to get them to know that they broke something or they changed something that they didn’t expect to change immediately. So, this measurement in tracking allows you to really look at the processes and start improving the process.

The next principle which we have is basically is to apply the best practices. What I mean here is, you know, what my grandmother used to tell – “Listen, Adam, you better learn from people who know better!” So what we are saying is, build best practices and these best practices might mean many things and they are listed in the book. One of the practices is, every time you implement something, build your server test case. Then, the other thing is, don’t write code which is a dangerous code. There is a lot of, lot of different practices which we have and they are much more detailed than what I am doing, saying right now.

And basically, these best practices are like applying consortium from other people who already know what to do in the industry.

BGB: Now, can I ask you a question –

AK: -- sure.

BGB: About best practices and about principle No. 4. You certainly can’t improve what you can’t measure. So the idea of measuring and tracking and then applying best practices, this is really a culture change, isn’t it? It is a way of committing yourself to continual improvement, which is what the SCI Institute has been saying for many years, but few organizations have the discipline to do today.

AK: Right. This is exactly what you just described.

BGB: Okay.

AK: And, actually, there’s a chapter in the book, how what we do really applies to SCI and to CMM and CMMI. And also how it applies to ISO. This is exactly what you just said. This is a culture change. The problem, I mean, you know. I am a great admirer with CMM, CMMI, I think this is a great idea. The problem with CMM and CMMI is that it’s not detailed enough, which actually it doesn’t tell people what to do with software. So, we think that with this book, we fill the gap which is this bottom gap which basically says, “Okay. What are the best practices, and how to apply them that this practices as KPIs in the terms of CMMI, get you to the Level Four in specific CMMI?”

So, if the practice is, for instance, coding standards – okay? We tell, you know, how to implement coding standards, which rules to implement, how to implement these rules, how to track them, how to measure them and then how to guide the process to success which is actually level V.

BGB: Now, can you automate any of this process in the infrastructure? Because what you’re saying, it’s the automated part that’s really exciting and different here.

AK: Yeah.

BGB: So that you can monitor and measure it through the lifecycle – Right?

AK: Right. So, there are two parts of automation. Always two parts of automation. The first part of the automation is preparation of the result. So part of the automation which, you know, when we have this automated process running, okay, scans the code and reports every violation of specific rule. Okay? Which is best principle, best practice. Now the problem with this is that there’s a lot of information. And if you don’t phase it in properly, you are overwhelmed. So what we do, is we create you a steady state and to the capability level which you want, which is really zero violations.

Now, the second part of automation, which is very important and it should never be underestimated as a work flow . What I mean by work flow is that how you distribute the work and to whom you distribute.

And then the developer or QA person comes into work. And logs into the IDE. IDE, there’s a set of tasks ready to be executed before the person should start the rest of the work. So this work flow kind of gets people in the rhythm of really working in this automated measure. You see what I’m saying?

BGB: Yes. So it’s implemented as part of the process.

AK: Yeah.

BGB: And automated. You’re sending it to him and that’s how you begin to change the process.

AK: Right.

BGB: Very good.

AK: And then, what the problem is that because it’s a culture change, it’s so difficult to do. So that’s why we have this principle, this principle No. 6. Okay? And principle No. 6 basically says, you need to do it incrementally. You cannot really go and try to do the whole organization at once. You get your server pilot group, typically the most capable group with one you can really work effectively. And then you implement and prototype the process actually in that group. Because every organization is a little bit different, so you need to really prototype and adjust the process for them.

And then you expand the practice, okay? To the other groups. And then you go to the organization. The same thing is, you know, you don’t take the whole practice. You take only part of the practice. And you implement it. And then you expand what more of the practice you are going to implement. And you go to the next practice. So you never implement two or three practices at once. So, you never implement, for instance, static analysis, unit testing and code review at the same time. You always do it one after another, even in the smartest group.

So this is, you know, very often in the industry when people buy software tools, they just want everything. They want their cake immediately. And they want the whole cake.

BGB: The silver bullet, right?

AK: That’s right, the silver bullet.

BGB: How long does it typically take to get an organization up and running on all cylinders to the point where they can increase their productivity by an order and magnitude which you indicated earlier, if they’re implementing these practices incrementally? So how, what, expected time –

AK: Yes, that’s a very good question. It’s a very slow process. We are talking between two to three years.

BGB: Okay.

AK: So, we are not talking one month, we are not talking two months. Now, you see the progress, okay? So you incrementally see improvement. You see many improvements. You see improvements in, for instance, your programmers, new programmers are actually catching up and becoming productive faster. Which is very important. You see the improvements that people who actually are in the organization are now able to handle more code.

AK: The real problem is, understanding. The software is complicated because it has many logical connections, right? Just like a spider on a web, whatever.

BGB: Absolutely! Certainly within SOA when you have just little pieces of functionality –

AK: Right.

BGB: -- that participate in multiple places. So impact analysis is huge.

AK: That’s right.

BGB: Do you have an information model that can live in a repository, that can track these connections?

AK: Yes. Exactly. That’s what we are talking about. Exactly. And then what you get out of – this is very critical, right? Because now the person starts understanding what is the, you know, what is the cause and effect relation of the code, right? So now you start understanding how it operates as a mechanism. And then the person improves. Okay? So productivity improves because now it’s getting better and better in the head of the person where to go.

Now, because you have this infrastructure behind you, then you effectively don’t need to do testing because the testing is done by the infrastructure. But, you need to fit this infrastructure with test cases. So people don’t distinguish between testing and creation of test cases. These are two different functions. Testing can be done automatically if you have test cases. Creation of test cases is generally a collaborative process which requires human intelligence.

Yes, we have tools. But these tools are not up to snuff with what our brains can do. So, what we are trying to say in our book is saying, the most precious thing that really exists in development groups are the brains. And we need to kind of take care of these brains and the artificial intelligence ability to create and free these brains from any tasks which can be done by computers. So they can really freely create whatever needs to be created. And when I mean, create – I put equal, equal footing basically creation of the new functionality and creation of the way to verify that this new functionality actually works.

We claim that application consists of the part which contains the functionality of the application and part which verifies the functionality of the application. And we claim that these parts are equal and they should be equal in size. Which means that you should have probably the same amount of code to implement the functionality as you have amount of code to verify the same functionality.

Which means that when you set up budgets of the projects, you cannot only think about your requirements. You basically have to double the time. Of whatever your estimate is to implement the requirement, because you need to implement the testing of that requirement. And you should double the budget, which I don’t think people understand.

BGB: You’re going to have to give them that ROI at the end of what it’s going to save them because it looks more expensive to begin with.

AK: Yeah!

BGB: They don’t want to invest in it. And I know in your book, you give the example of Dr. Demmings trying to tell the American auto industry about the ideas of defection and you know: plan-do-check-act and he went over to Japan and they embraced what he said. They gave some medal of honor, the Imperial Medal of Honor, and their cars are much better than ours, actually! They beat the pants off of us.

AK: Well – look. Right now, right now. Ford and GM are in trouble, right?

BGB: Yes.

AK: And we don’t know they are going to survive. And Toyota and the other Japanese car companies are surviving.

BGB: Exactly!

AK: And it is because of Demming.

BGB: Yes.

AK: It is because of Demming. Now there are other problems here, we had unions and we had different things. But Japanese also had unions. The difference is that everybody in Japan got very serious about really improving this quality and you know what happened? They got serious about improving the quality but they actually improved the productivity because they removed the ___ (22:44) and that’s why it’s so difficult to compete with them. Because their product is better but actually their product is cheaper because they can produce it cheaper.

BGB: Yes.

AK: Of course, nobody wants to talk about it because it’s kind of not a politically correct story. But the real story here is that if you try to, you know, if you don’t want to take seriously the production methods, you are never going to produce.

BGB: Yep.

AK: You will be limping your way through the production process but you will never get it right.

BGB: Yes. I think you have very important things to say! I highly recommend that all the development managers out there go pick up a copy of this book, Automated Defect Prevention, and I will provide a link in the blog as well so they can get it. So thank you for taking the time to talk with us today and hope to hear more about this in the future.

AK: Thank you very much. It was my pleasure.

Posted by bethgb in Industry Trends • Podcast • SOA • Vendor Briefings | Permalink | Comments (0) | TrackBacks (0)