IBM Podcast [ MUSIC ] MATHENY: Welcome to this IBM podcast, Create Stable and High Quality Software Creating Software That's Flexible and Secure by Design. This is step two in the Five Steps to Reduce your Cost of Quality series. I'm Angelique Matheny with IBM. Software delivery is a challenging proposition, but there are steps that can be taken to reduce cost and risk and still deliver applications and services on time and on budget. In this series, we'll examine five strategies software delivery teams can take to ensure application quality while maintaining a focus on cost and customer expectations. This second installment in this podcast series picks up where episode one ends. We start by discussing the importance of starting from requirements to ensure traceability and validate that real business and stakeholder needs are being met by the solution that is being proposed. Then the podcast moves to discuss best practices in software architecture, the latest development in capabilities in Rational solutions, and what you can do to make the best use of these advancements in software design and development. -1-
And joining me today is Adeel Omer, Marketing Manager Architecture Design and Construction. Thanks for joining us, Adeel. Let's jump right in. So, Adeel, we've talked about requirements in business analysis in the first podcast in this series. Where does service architecture come in to help create better software? OMER: Thanks, Angelique. When most people think of architecture, they think of simple diagrammatic blocks, but the true importance in the capabilities of architecture are often overlooked. We live in a very complex world. And there's very complex software and very complex systems that make up the solutions that we need these days. So the place where architecture comes into place is, first of all, it helps create a traceability of the solution that you're creating to the requirements. Whoever your stakeholders might be, could be your business, could be your customers, there always needs to be this sense that your solutions map back to the requirements that were created. So integration with your existing business processes is a must. Understanding the impact on existing business processes and perhaps designing new ones that don't break existing business processes. So that traceability to requirements in your existing business processes is number -2-
one. Number two, you want to have traceability to your enterprise architecture. So you've got an existing infrastructure of IT and infrastructure of various systems, and you have to make sure that your new solutions merge well with those existing IT infrastructures. To do this, there's business process modeling notations, there's SOA modeling notations, there's all sorts of industry standards that you have to comply with. And to make sure you comply with those standards and to comply with your enterprise architecture, you have to follow a lot of architectural processes. And then finally, working with those two allows you to have a large amount of reuse of existing assets. It saves time, it improves quality, it improves your time to market. So with integration between your architecture tools, your enterprise architecture and your IT infrastructure and your services, those integrations can help you when you're automating your deployments. It can help communication between architectures, architectural teams as well as stakeholders and operational teams. So that's how architecture helps to produce better software in the long run. -3-
MATHENY: You know, it's often overlooked. Why is that? And what are some of the potential side effects? OMER: So, yes, architecture does get overlooked, where nowadays we're almost in a rush to get to market and be the first one to market. And that's great and it's well and good, but you must not overlook the due diligence of at least just enough architecture to take care of some of the concerns that I already outlined. But going to the potential side effects, if you want to manage the complexity of a really large and complex solution, you know, it might not start large but eventually it will get there. You know, software lives forever, and so you have to make sure that these large complex solutions can always be flexible, scalable and they can be migrated over to other systems, if that's what the need might be later on. So having the ability to create flexible software is truly important, and that's the potential side effect is your software might not be open to change later on. The second thing that can really cause a lot of trouble is if you're not compliant to either existing standards, or -4-
you're not audit ready, or you don't comply with the requirements, because that traceability thought that I talked about is really important. And then finally, if you have different people working in silos or if you're in a rush to provide whatever software you're in, you know, you've got two weeks and you say, okay, I'm going to come up with a software in two weeks, what you might end up doing over time, those little iterations, if you don't do proper due diligence with your architecture, is you might be creating patterns in your software that are known to cause certain issues, whether it's with performance or security or whatever. So that's essentially patterns-based engineering, and there's a patterns analysis engine that you can find in certain architecture tools such as Rational Software Architect. It not only detects what patterns you are creating, but it also detects anti-patterns, which are bad practices. So what's important is later on, when time period comes to change your applications and you try to change what the code is, a) it's going to be impossible, unless you have an architecture, because somebody new could be in the role. Or you just want to understand or get a primer on how things are set up. That's going to be impossible. -5-
But then, secondly, you might have implemented some anti-patterns, which make it impossible or very tedious to change your software. So those are some of the risks. You have to manage the complexity, you have to be compliant. You have to have a flexible code that complies with the business processes. And then, finally, you want to make sure that you are not creating any anti-patterns, and that if there's any industry-specific patterns, that you are following those just to be compliant and be part of a best practices. MATHENY: Adele, can you give us some specific examples of how software architecture tools such as Rational Software Architect can help software designers produce that high- quality software that you just mentioned? OMER: Sure, Angelique. We know the importance of standardized modeling is you create projects and you manage your risks more effectively. And you can design your solutions pretty much at a high level. Now, to do that, there's specific practices as part of architecture and design that you can perform. Now, you can leverage the power of abstraction, visualization, traceability, all the neat things I talked about, and -6-
analyze the impact of any changes later on. So one of the biggest aids in doing this is patterns-based engineering. Tools like Rational Rhapsody and Rational Software Architect have a patterns engine, and what it allows you to do is to create patterns or use existing patterns. There's a library that comes with the Rational Software Architect that you can use to get a boost in how you go to market and how quickly you can design your software. But you can, in addition to leveraging any included patterns and using some transformations to design your software, you can also create your own patterns. The other thing you can do is you can create custom domain-specific languages, both graphical and textual. What that allows you to do is if you're working in, let's say, the automotive industry and you would like to create a description of a vehicle, or you're working in a certain industry and there's specific business processes that you have to model, then you can create your own artifacts to model them. What this allows you to do is communicate more effectively with the people who consume those models. So it's not just in the domain of the technical architect, but it's also the -7-
operations people who can see, all right, this is where the architecture solution is going, and they can provide some feedback before it's too late. Then you can create custom factory solutions based on your own domain examples, what I just talked about. The other main example, the way you can use architecture, is using industry-specific modeling profiles. So within Rational Software Architect we have an extension called the Modeling for Communications Application. I'll use that as an example. What it does, it adds on to the basic modeling profile that allows telecom service providers and pretty much anybody who has a Web presence is to quickly create the architecture of their solutions and to actually implement their solutions as they relate to communications applications. So let's take the example of, you're a realtor and you would like people to come to your Web site and quickly connect to you by clicking on this click the call button. Or, if you want a customer service line, and you click on this button on the Web and suddenly the person who is on the Web site, their phone rings and you can get connected to them. It's a better experience, but it has to be done in a structured, proper way. -8-
What Rational Software Architect will allow you to do is take the standard session initiation protocol and [engulf] Web services and kind of hide all the complication from you and allow you to create the architecture of your Web application so that you can connect into these services without having to do a lot of work. So that goes for just the teleco example, but you can do this with a bunch of other examples as well, or other industries as well. And one thing that's really overlooked is deployment modeling. So deployment, planning and modeling is kind of a new angle to the way you can use architecture tools. We know we can create models of the software, but how do we create the model of how this software is going to be deployed on my servers and my databases? And then, how do I know if I had the right infrastructure ready or not? So this angle of architecture, you know, deployment modeling, what it allows you to do is before the software ever sees the light of day, you decide how it's going to get deployed. What the minimum requirements might be, and talking as a domain-specific profile. The operation guys might look at this and say, hey, you're asking for five app servers, we don't have them. Are you sure you need them? You say, yes, I do. They say, all right, we'll order it. It takes a month. That's how long -9-
it will take you to write your software so we'll have everything ready by the time you come to deployment time. As opposed to, hey, I'm about ready to deploy, do you guys have five servers? No, we don't, you'll have to wait for a month. So it reduces the risk, it allows for better communication between various teams that are involved with software development and that's really just another angle of how architecture can help with software development. MATHENY: And our last question today, Adeel. How can everyone get their hands on you'll these neat solutions or find out more and see them in action? OMER: Okay, great question. So the main product that I've been talking today about is Rational Software Architect, and there's a fantastic resource in the Rational Software Architect wiki. Controlled by the support and development teams, because they're very tied up with it. There's tons of good videos. There's pointers to great articles. So if you just Google Rational Software Architect wiki you'll be able to get to it and get to all these neat little tools. If you want to check out the development tools in action, there's the Rational Application Developer wiki that you can get on. But if instead of watching the video you want to -10-
actually get your hands dirty, the trial download for Rational Software Architect, Rational Application Developer are available. You can download them and then play with them or just work with them online. There's an online hosted trial where you can just play around without having to download any of those products. And then finally, if you're interested in the latest and greatest capabilities that are out there, you'll see on the Rational Software Architect wiki that we are currently running an open beta program for Rational Software Architect. And you'll see a lot of videos of what the cool new capabilities are of this beta, including model simulation, which allows you to create animated simulations of how a flow might take place within your architectural model. So give those betas a shot. Check out the Rational Software Architect wiki and check out the trials. MATHENY: Adele, as always, thanks so much for sharing your time today to discuss this podcast, Create Stable and High-Quality Software, Creating Software That's Flexible and Secure By Design. We really appreciate it. OMER: Thanks, Angelique. -11-
MATHENY: That was Rational's Adeel Omer, Marketing Manager, Architecture Design and Construction. To share this podcast with your colleagues, or if you're interested in more podcasts like this one, check out the Rational Talks To You podcast page at www.ibm.com/rational/podcasts. We'll include the other steps to the Five Steps to Reduce Your Cost of Quality Series. We'll also include a link to the Rational Systems and Software Design site. So check it out today. This has been an IBM podcast. I'm Angelique Matheny. Thanks for listening. Keep tuning in as Rational Talks To You. IBM Podcast [ MUSIC ] [END OF SEGMENT] -12-