I recently caught up with John Schmidt, who has recently joined Informatica as the VP, of Global Integration Services. John is also the Chair of the Integration Consortium, and is now helping Informatica define a set of best practices and services for implementing an Integration Competency Center (ICC). John stated that when Informatica polled its customers and asked what they would like to see Informatica invest in, it was in helping them create the ICC.

Now, this intrigued me because, if the truth be known, lately I've been taking the "I" off my ICC slides and just renaming it the Competency Center for SOA initiatives - the thought being that integration efforts are now being subsumed as a part of SOA, or as an enabler to SOA - but becoming less of a separate initiative. But John insisted that integration was indeed important in and of itself, and is being driven by enterprise strategies for aligning IT and Business, (and this includes SOA), and the need is to create formal governance processes and this demands and ICC, The second driver John mentioned is data warehousing and business intelligence, and the need to create a common view of the customer, or a 360 degree view of the business. These initiatives include master data management and integration. The third driver John mentioned is regulatory or other compliance issues, data security, and privacy, where the ICC becomes the center for maintaining data quality.

Must admit I had some difficulty getting my mind around the last one. The ICC responsible for Data Quality? Isn't that the realm of the data center, which most large organizations have had in place for years? But John insisted that federated data requires a centralized governance group to manage the canonical models and map the semantic meaning of data across business domains.

In my experience, data governance is more about politics than anything else - who owns the data and who can access it. And of course, governance needs governors. If no one is responsible for enforcing governance policies, how is governance going to actually be implemented? So I agree that these issues of control and governance of distributed and federation information require some changes to the org chart in order to make them happen. But what is the correct organization and what should the responsibilities of a CC be?

John Schmidt outlined core competencies he has defined as part of the practice:

1. Financial management. The ICC operates as a shared service. This is a set of best practices around charge back for shared infrastructure and individual services.
I think this capability is definitely needed for SOA as well.
2. Architecture . The ICC does not do enterprise architecture, but is responsible for the information architecture. They work with the enterprise architecture group, and "connects the dots", by mapping schemas to physical data sources to enable the translation, transformation, and integration. This ICC is the central federated repository.
I asked John what he thought about using semantic metadata to enable this instead of all the proprietary mapping techniques, and he responded that it's not a viable alternative today.
3. Business Process Management. According to John this is not BPM per se, but this includes service flow modeling, information flows, business event modeling, and common definition of business events.
Sounds to me this is more about SOA, than integration.
4. Integration methodology . The process of running an ICC, defining it, organizing it, all the things you need to run an integration group, and how it will interact with other IT groups.
5. Metadata management . The core tool is the metadata repository. The ICC group is responsible for data assets. Metadata ends up being a federated model. There are multiple repositories, and all have different views. The ICC understands the federated model and focuses on the key integration points between the different parts of the organization.
6. Modeling management . This includes techniques around canonical data modeling, what are the best practices, how do you build them.
7. Integration Systems. This is about running integration systems as a specific class of applications – all the discipline of how your manage, plan and operate the system. Formerly, when he was at the Bank of America, John Schmidt was responsible for running the the biggest Web methods integration system in the world. There was never any time when there were no transactions going through it. He said doing maintenance is like changing the tire while the car is moving. – how do you do maintenance. Changing tires on the care when it’s moving. Business rules, hierarchy of services. All needs to be managed. Integration will be a core competency and discipline.

In his book, Integration Competency Center: An Implementation Methodology, John defines different ICC models:

While I absolutely agree with John that organizations truly need to develop core competencies in integration, I think it is less clear what the roles and responsibilities of an ICC should be, and some of that depends on how organizations approach integration - whether it is a strategic initiative in itself, part of a an SOA strategy, or (as it is in most cases) a tactical solution for implementing a new business capability, as well as the model of the ICC or CC, or SOA CC.

While some of the roles and responsibilities John outlines may not all fall within an ICC, I think organizations that are seeking more agility through integrated solutions that cross existing application boundaries, need to think about these roles and responsibilities and define where they lie within the organization. Without governance we're going to to fall into the lawlessness of the wild west, and distributed, federated approaches will quickly run into problems. Governance requires governors.

So where do you fall on this spectrum? Are you building an all encompassing ICC? Are you creating different org structures? Are you experiencing the pain of having to make these decisions yet?

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

There is a very big movement in the industry away from after-the-fact reporting and analysis to on-demand information delivered in context, what some are calling operational BI. Last year ebizQ did a virtual conference on BI in Action during which we had a panel discussion on BI and BPM, and how BI was evolving into more on-demand, operational BI. The overall message was clear. Organizations are seeking more in-depth information on-demand, within the course of business, as opposed to periodic, after-the-fact reports.

I recently spoke with Truviso about an innovative approach they have developed for delivering on-demand information in high data volume environments. As Roman Bukary, VP marketing and business development, explained it, instead of executing SQL queries against large volumes of data, Truviso analyzes the information as it moves through the pipe. It actually uses standard SQL, but can apply queries to high volume data streams, and feed dashboards with the information or even trigger data-driven actions and alerts.

The company was co-founded in 2005 by Berkley professor Michael Franklin and his assistant Sailesh Krishnamurthy, who is now the chief architect. They developed an engine that uses standard SQL queries to analyze data as it moves across systems, regardless of where it comes from. The result is massive scalability and performance, clocked at 100,000 records per second on a single machine. Additionally, thousands of concurrent queries can be run continuously and simultaneously on a single server, and the queries can be run over both real-time and historical data from within a single engine. Truviso uses open source database PostgreSQL which enables data to be optionally persisted for replay, back-testing, drill-down, bench-marking and other purposes. The system can be run distributed across applications, databases, and edge devices, allowing for massive linear scalability. The system includes integration components so it can accept data from multiple different sources, including message queues. Each connector is provides transformation capabilities.

Foreign currency trading was the first market Truviso entered. They also have solutions for capital markets, retail inventory, logists, SOA/Network monitoring, and RFID/Sensor Network.

Because it built on top of PostgreSQL, it can deploy natively on any OS or hardware platform. It can run in a virtualized environment, and Truviso is (or will soon be) available as a SaaS solution. Because it uses standard SQL companies can migrate historical reporting to real-time analysis in a matter of hours.

BI meets event processing. On demand BI. Intelligent event processing. This technology seems to span categories, as well as uses in the enterprise.

Posted by bethgb in BI • Business Intelligence • EDA • Industry News • Industry Trends | Permalink | Comments (0) | TrackBacks (0)

One of the things that swamped me in the past month was setting up a new computer. Never fun. This one was interesting as I was forced to migrate to Vista. There has been a lot of talk about Vista in the industry, especially it's failure to succeed. InfoWorld is spearheading a petition to keep XP, and I even signed the petition knowing I would be buying a new computer soon. This week InfoWorld published an interesting article "Was Vista DOA?" The article talks about the early bugs with drivers that did not work and compatibility issues. But this paragraph summed it up for me:

"Here was an OS that, from an enterprise IT standpoint, had almost nothing going for it: No major new technologies; no paradigm-shifting architectural changes; nothing to whet a system administrator's appetite. What it did have was layers and layers of consumer-focused baggage: Pervasive DRM plumbing; dubious multimedia prioritization tweaks; OS X-envy driven eye candy. Basically, it was an OS designed to secure Microsoft's seat at the RIAA/MPAA roundtable, and little else."

Here was the eye opener. Vista represents little more than an expense for IT departments - it has nothing else to offer. But I must admit, even after having to spend more than I would have liked to upgrade software which was admittedly old but still did the job I needed it to do, I like Vista. The user experience is a big improvement over XP. Eye candy is part of the appeal. But it all seems to work more smoothly. It's easier to use. There's less arm wrestling with MS Word and Powerpoint. Things are more integrated. It feels more productive. Now from an IT enterprise point of view I have to admit it's probably not enough to justify the expense. But it made me understand the appeal of the Mac. My son-in-law asked for the new Mac OS for his birthday. Can you imagine any PC user wanting the gift of an operating system for their birthday? Usually I'm squarely on the side of enterprise IT, but I'm starting to change my tune a bit. The end user experience should not be discounted as unimportant eye candy. IT needs to enable a smooth and seamless user experience. It cannot be a mere secondary afterthought to other IT requirements.

Which brings me to my musings on Web 2.0. On Mar. 19th ebizQ held it's first Web 2.0 virtual event, a live Roundtable Discussion on Web 2.0 and SOA (you can view the archive). We had an all-star panel including Dion Hinchcliffe, Ron Schmelzer and Doug Wilson, and they were all great at explaining the role and benefits of Web 2.0 in the enterprise. But the audience questions were equally interesting. One attendee stated that while blogging was successful in the enterprise, they experienced problems with viruses from social networking sites such as Facebook, even after deploying all the virus, adware and malware protection, and wondered what the ROI was for the organization. Another attendee wondered if spending time on social networking sites meant lost productivity of employees. Dion Hinchcliffe said they have reviewed all the case study data and there is definitely an ROI for Web 2.0. Doug Wilson of IBM stated that internally deployed social networking software has lead to increased productivity across the organization. He made that case that many business services are executed by humans who need to interface with other humans as well as systems to do their job. Web 2.0 provides the support to carry out human based business services which in turn rely on back end system services.

So the whole idea of how humans interact with computers is becoming more important in the enterprise. Interestingly, a poll of attendees showed that 50% of the live online audience were investigating Web 2.0 solutions, 13% were piloting them, 38% had Web 2.0 solution(s) in production, but 0% said that Web 2.0 was prevalent throughout the organization. However, Doug Wilson indicated that the social networking solution internal to IBM is largely responsible for enabling the the highly matrixed reporting structure and enabling people to connect more easily.

Bottom line - Web 2.0, while difficult to precisely define, is here, growing, and likely to change our expectations of the way we work. In the future, we are going to expect a seamless experience. We are going to be less tolerant of being forced to do things the way IT works, we are going to expect IT to enable the way we want to work. So shame on you Microsoft for creating an OS that enterprise IT doesn't need but end users do. And shame on all the IT folks dismissing Vista as DOA and not considering for a moment the benefits of the human interface advancements as being valid. There's a lesson to be learned on both sides.

Now I think I'll go tag something.

Posted by bethgb in Industry Trends | Permalink | Comments (0) | TrackBacks (0)

Today TIBCO announced general availability of TIBCO ActiveMatrix™ 2.0 which is designed to simplify SOA development, deployment and management. While SOA is being widely recognized and an architectural best practice for enabling business and IT to respond quickly and more easily implement new solutions, SOA is not a single technology, which makes it inherently complex. The challenge is to get all the different technologies that comprise a SOA solution to work together easily.

TIBCO’s ActiveMatrix allows companies to design, develop, deploy, manage and govern SOA solutions without having to worry about each of the underlying technologies. It is a grid architecture that enables different technologies to be “plugged in”. The grid provides the integration and common management and governance across all the technologies.

In ActiveMatrix 2.0 BusinessWorks now runs natively as a container. You can take existing BusinessWorks projects, including BPEL orchestration, can compose it with java or .Net and deploy and manage it all as a single application. Adapters also run in service containers. You can take a configuration that defines what functionality is being exposed from the application, such as SAP or a database, deploy it in an ActiveMatrix container, and it becomes a fully managed service.

ActiveMatrix 2.0 has added a new standalone engine for service mediation. Tibco has unbundled the service bus (ESB) from BusinesWorks to provide a lower price entry point for developing new services that can be plugged into the ActiveMatrix platform.

TIBCO has also expanded its SCA support. SCA emphasizes the decoupling of service implementation and service assembly from the details of the technical infrastructure and access methods used to invoke services. SCA components operate at a business level and use a minimum of middleware APIs. The companies contributing to the SCA standard include: BEA Systems, Cape Clear Software, IBM, Interface21, IONA Technologies PLC, Oracle, Primeton Technologies Ltd, Progress Software, Red Hat Inc., Rogue Wave Software, SAP AG, Siebel Systems, Software AG, Sun Microsystems, Sybase, TIBCO Software Inc. As more companies build SCA support into their platforms it will make services easier to deploy. This is TIBCO’s goal is supporting SCA.

ActiveMatrix 2.0’s SCA support includes a composition editor as well as expanded deployment and management support. It provides an integrated service view which shows a service with all its dependencies. This enables operations to more easily understand what might be the root cause of a failure. Policy management is also available for all services. When services are built with ActiveMatrix all the SCA annotations are automatically generated. TIBCO claims this contributes to up to 50 percent greater productivity and lower cost of ownership. Integration, maintenance and governance are built into the platform, and available regardless of the technology used to develop the service.

ActiveMatrix 2.0 can also import process models developed in Visio or Aris, make them live, and tie them to the applications. The integrated registry and repository can then show how business processes are impacted by changes. This allows better alignment between IT and the Business.

From a pure architectural standpoint, ActiveMatrix 2.0 represents best practices for creating an integrated infrastructure. It simplifies SOA by providing a set of common infrastructure services to all business level services, regardless of technology difference, making it almost as easy to deploy a new business service as it is to plug in a new appliance into the electrical grid.

Posted by bethgb in ESB • Industry News • Industry Trends • 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)

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)

In this podcast I spoike with Hub Vandervoort, CTO at Progress Software about his ebook titled “SOA: Socially Oriented Architecture”. In this book Hub talks about a the people and management side of complex SOA environments that cross organizational boundaries, and what is necessary to enable people to work together effectively. Transcript follows below. Let us know what you think. Does this strike a chord with some issues you are dealing with in your SOA evolution?

Listen to or download the podcast below: