By: John Kaster
Abstract: Read the transcript of the live audio chat from June 28, 2005 on Innovations in Modeling with Marc Brown and Tom Gullion
Transcript of live audio chat from June 28, 2005 on Innovations in Modeling with Marc Brown and Tom Gullion.
John Kaster: Good morning, good afternoon, good evening everyone. I’m John Kaster, Principle Engineer of Developer Relations and Evangelist for Borland. Anders Ohlsson, Staff Engineer of Developer Relations and Evangelist for Borland, is running the chat today.
Thank you very much for taking the time to join us for this live chat on Innovations and Modeling. Borland greatly appreciates your support and interest.
Some quick reminders before we get started: This audio chat is intended for technical information only. The opinions expressed in this briefing do not represent plans or statements of intent of Borland, but the personal opinions of the people speaking in the chat. When you want to ask a question, use the /ask command, or the Ask link in the chat window to submit questions to the moderators.
With us today is Marc Brown, Director of Product Marketing for AOM Products, and Tom Gullion, Product Manager for Together Technologies. Marc and Tom will be discussing Borland’s latest advancements in modeling, with a special focus on Together 2006.
Guys, thank you very much for coming today
Marc Brown: Thank you, John!
Tom Gullion: Thank you!
John Kaster: So, the first thing is, this is a JavaOne chat. What are we doing in JavaOne? What are you guys talking about there?
Marc Brown: John, from a Together perspective, Together 2006 was announced yesterday. It’s really the next installment, really the evolution, of a Together modeling family. Together 2006 continues Borland’s initiatives around bringing to the market role-based products specifically tailored for specific individuals within a development organization. Together 2006 is fairly exciting for us because it really is a convergence and culmination of many of the best practices in best of breed features that Together technology has brought to the market for some time, but done so on top of Eclipse 3.1. So, Together 2006 is comprised of a Together designer product that is specifically targeting the analyst’s role.
One of the things that I want make sure that we have the ability to do today on this chat is be able to address specific questions and concerns for each of these roles that we’re targeting.
We also have Together Architect 2006 that is bringing to the market a host of capabilities for the architects to allow them to do their jobs more effectively, basically bridging between the analyst and the requirement space and the development community that’s responsible for actually building the final application.
Finally, we’ve got Together 2006 Developer that is addressing the developer community. We’re here at JavaOne. Borland continues to be pushing and actively promoting capabilities to help organizations do job applications more effectively. Together 2006 just brings more capabilities to the market, more capabilities to those developers, and, overall, to those teams to increase their productivity.
John Kaster: Tom, is there anything you want to add to that?
Tom Gullion: Yeah, we have some very specific features that the Java community certainly should be interested in. You know, this is the next logical evolution of TogetherControlCenter, renamed Together Architect, so this is really the next big release for our Together customers that have been hanging with us all these years. With this we also have the ability to generate Java 5 code doing assertions and generics and all that, even driving that from a file in the model too. We’ve really taken some of the best features of different pieces of MDA, Model Driven Architecture, and provided them in a very usable way. So, even if you don’t buy into the MDA dream, you can do model-driven development with this tool in a very effective way.
Marc Brown: I think that the real cool part there, Tom, is the fact that by out-leveraging some of the model-driven development components, Java developers can remove some of the tedium that they are faced with right around generating a whole host of tools just to maybe define an interface. The tool will automate some of that for them and allow them to focus on the real application logic that the requirements are demanding.
Tom Gullion: Absolutely.
John Kaster: So, you’re talking about leveraging model-powered development a lot more. Are there other reasons why? You’ve both said this is a very important release, so can you give me some break-down details on why this is such an important release for Together?
Marc Brown: I think the first place to start is really looking at what Together 2006 has done from an organizational perspective. If you look at Borland’s history, they’ve continued to improve upon individual development productivity. We’ve done a lot of things to improve individual’s capabilities. With Borland’s recent announcements around the software delivery optimization vision we’re really looking at how we can more effectively increase an organization’s efficiency and how to help them be more effective at delivering software, the right software, on time and within budget.
Together 2006 has brought together a common set of visual models to really connect up an organization. One of the new things that I think is fairly exciting is the introduction of Business Process Modeling. It’s now available in Together 2006. This is new for Together and it really provides a facility for the business analyst to fully spec out their business processes in a visual way. That really allows them to document those business processes in a visual way, optimize their business processes, then take those definitions and specifications and move them downstream into the IT organization, really helping the collaboration and communication between the business and IT analysts. So, that’s one introduction that I think that this particular new version, the 2006 version, will bring to the market.
I think another exciting new capability is just increased capabilities around model-driven architecture. There’ve been a number of organizations talking about the importance or the value of MDA, but, again, all too often it’s been something that’s been very difficult to do without leveraging a proprietary solution. There are a lot of vendors on the market today that are talking about their MDA support, their MDA solution. But, fundamentally, it usually falls back down into using a proprietary framework targeting a specific platform. What Borland has done is implement the query/view transformation specification that’s been put forth by the OMG. It defines exactly how model-to-model transformation should be done. This is an industry-standard method for doing model-to-model transformation. This will give organizations the flexibility, and, really, the independence to now define independent models that can be targeted at multiple, unique platforms. That’s another, I think, exciting capability.
And thirdly, we’ve expanded our capabilities around ensuring that the models and code that are going to come out of Together are complete and consistent. We’ve offered audits and metrics for some time at a coding level, but those particular capabilities have been leveraged by the Java community for some time to ensure that the Java code that’s being developed is being developed in a way that follows naming standards, that follows simple Java best practices, and is also being done in a way that is going to be maintainable in a cost-effective way as the application evolves over time.
We’ve extended that capability now to the modeling level to allow organizations to now do audits and metrics on the models themselves. We have the ability, now, to verify that the development team and the architecture team are following naming standards put forth by the organization, building consistency throughout the organization. It also allows the organization to ensure that the designs and architectures are fully specified. This is really important if you are doing a design that is going to be handed off offshore to maybe a distributed team of developers who are going to be dependent on looking at a fully completed design. So the audits now can go through and verify that the model itself has been fully specified, really helping us to ensure that what’s turned over to the development team is complete so that what they actually develop is what we expect.
I think those are three huge pieces and those really touch on a number of things. They really bridge the business and the IT organizations and span multiple roles.
Tom, do you have anything else to add to that?
Tom Gullion: Sure. Marc has certainly gone down the new feature list and given you a huge feature dump, so, to put your fears at bay that, um, ‘Oh my gosh, this is going to be an uncontrollable product!’, we’ve really implemented this leveraging all the best features of Eclipse
as an integration platform so that we have perspectives that equate to roles and you can turn on and turn off capabilities as required so you can fine-tune the heap size on how much memory your tool is taking, you can fine-tune what parts of projects that you are working with by selecting different perspectives… All this provides a very usable user experience in that that’s really one of the big themes of what this product can do. So, it’s a quantum leap for Together products in general in that now we can have all the roles working within the same workspace, all project artifacts are usable throughout the entire lifecycle. The artifacts can be all managed within Version Control, hopefully using StarTeam, and then also can be linked to requirements hopefully using CaliberRM…RequisitePro can be used as well.
Marc Brown: Yeah, I think that’s an important point, Tom, that Together is basically unifying the desktop. So, whether you’re an analyst, an architect, or a developer, the capabilities needed to do your job are exposed in a certain way that’s very intuitive to you. But also all the connections to the rest of the ALM suite, whether it be an activity, change system, whether it be a version control system, whether it be a requirements management system, whether it be your IDE and development testing capabilities, all those can be exposed and integrated very nicely within the Eclipse platform.
John Kaster: If we can back up for a second, a question that came in during the chat from one of the people listening is: What exactly do we mean by business process modeling? Is there a relation to business workflow process modeling engines like jBPM? Is that the type of thing that you’re talking about?
Tom Gullion: We are implementing the BPMN spec. This is business process modeling notation which was set forth by BPMI.org. You can do fully relevant business process modeling and then you can also generate BPEL, specifically BPEL for web services from that. It provides best of breed specification of where modeling as well as validation features so that as I’m defining that diagram and setting that up so I can spit out BPEL for web services, I have automated validations in the background and then I can finally generate that BPELfile, or I can use that in the container of my choice.
John Kaster: A recurring thing that I’ve been getting from what you guys have been talking about so far, and also what Together has done historically and what all the Borland products have done historically, is this breaking down of barriers. The big challenge that people have when they are adopting new principles, new practices, or new technology is this disconnect between one piece, usually design, and the implementation. You did a great job with Live Source for Together with that. But now you are totally raising the bar and involving business units and human processes and things like that in what you are trying to provide a solution for. So, how is Borland going to move Together up from its traditional very code-centric and design-centric roots to this whole business process environment for both so that it caters to all the roles in the solution rather than just the classic development roles?
Marc Brown: We think one of the things that Borland is trying to do here is leverage visualization across the board. What we’ve found is that as organizations are faced with more business challenges, organizations are faced with less money, less resources, and tighter time constraints. They are also faced with higher, more complex applications. They are basically looking for ways to help automate and visualize what they are actually trying to do. This is something that we are now seeing expand definitely outside of the developer community into the analyst areas and the architect’s areas. So I think Together and many of the visual modeling tools over the last decade have certainly focused on architecture and some of the high-level designs.
What we’re now seeing is real value coming in on the front end where we’re looking at requirements and requirements themselves before they’re validated and put into an IT organization for implementation. Those requirements themselves need to be validated in some way. They need to be understood. Business analysts are looking for ways to basically articulate what’s needed from a business perspective, whether it be a new business process or alterations to existing processes, in a more intuitive fashion.
By visualizing processes or by basically doing analysis of requirements using use-case modeling, it gives all parties involved basically a different perspective. It’s a lot easier to look at a picture than it is a huge document with multiple paragraphs of text. It really leaves the analysts, the customers, all parties involved with an understanding of what’s being defined. Unfortunately, what organizations have seen, if requirements or desires are put in textual form, there’s always the human form factor, right? Humans can basically communicate and articulate things much more effectively in pictures. We’ve done that for centuries and centuries. There’s a lot of interpretation that happens when you draw upon text. What we’re trying to do from a Together perspective is to build in some of the facilities that span into the business analyst space that really tie into the IT analyst space that touch on the system engineer to give them more capabilities to allow them to facilitate, really, the articulation and the communication of those requirements more effectively so they can get customer or stake-holder buy-in in something they have confidence in that’s agreed on by all parties.
I think the other thing to mention here is this notion that some of these capabilities that we’re offering in the Together 2006 offering will be capabilities that will be joined together in our Core Analyst, in our Core Architect, in our Core Developer offerings, within our Core FTP set of offerings. Core FTP was announced back in February. There’s this notion that we’ll be basically delivering specific products that are basically targeting a particular role. That product is broader. It doesn’t just have modeling facilities, but it has the foundational capabilities so that is has some capabilities around software configuration management, some things around change management, some issues or capabilities around process. It’s really the coupling of capabilities and then exposing those capabilities in a very role-centric package that I think Tom and I mentioned earlier in this chat. Tom, anything to add there?
Tom Gullion: Yeah, it’s interesting – one of the things that we’ve certainly learned about visualizing text, you know, with Control Center, features we’ve historically had with Live Source where we help you to visualize the model that’s inherent in the code, is that there is so much to benefit from the visual metaphor and from visualization of complex text in source code and all that. But, then there’s also a problem there. It’s a sort of a Catch-22 situation where I gain understanding because of the abstraction and the reduction of complexity, but then I also lose some understanding. So, one of the things that we’re hoping to accomplish with model audit and metrics is exactly what we were doing with code audit and metrics against code with those lower level inspections that the computer excels at. This is the ability to visualize things like the business process model, the UML analysis model, the ability to check for completeness, the ability to check for consistency. It’s a vital thing, so, we’re providing both sides of that coin.
One of the advantages of that is that I think it’s going to smooth the hand-offs, so to speak, between analysts and developers. Typically, there is not a whole lot of trust there because one just sketches diagrams and the other has to consume them and write code against that and, well, we all know how effective that’s been in the past. So, there’s generally some suspicion about, well, Yeah, right, it’s fine to draw it but try and go off and spin it up in code. So, to the extent that we can put as much intelligence behind the models that are defined in the business process model and those analysis models, it’s just going to streamline and improve quality and improve the way we work together all the way down the stream.
John Kaster: So, you both have been tossing out names for roles and, actually there, also SKUs for products for Core FTP, talking about how we’re catering capabilities to particular roles. Can you actually list the roles that we’re currently supporting? What the highlights of those roles are? Why we’ve classified them the way we have? And why we’re taking the approach to solving their needs the way we are?
Marc Brown: Sure. I think there are two perspectives here:
If you look at the Together 2006 offering, as I mentioned at the beginning of this chat session, we’ve got a new offering called Together Designer 2006. That particular offering is really targeting the analyst community. Some would say, ‘Well, what do you mean by that?’ Well, the analysts themselves are those individuals who are responsible for either the definition and specification of requirements or the analysis of those requirements. It really spans both the lines of business and the IT organization or the engineering organization, so, it falls on both sides of that spectrum.
Your business analysts are, many times, domain experts. They have great insights on what’s required from a particular domain. Many times they are not technology experts. They can very easily articulate what’s needed in a particular domain and they need to be able to do that in a very effective way with minimum technology difficulties.
Then, as I mentioned, on the IT or the engineering side, you’ve got analysts who really are responsible for taking that customer or line of business requirement and transforming it into a set of requirements that are going to be used by the development team to create a system or application. And they have to boil down those high-level customer needs or business needs into a set of functional and non-functional requirements. So, you can think of those individuals as people who are much more technology-savvy, who would also have some degree of domain expertise, and who would really be kind of the bridge between the business and the development squad. Their role is actually very fundamental and it’s paramount that it’s done right because it leads all the downstream activities as to whether something is going to be done right and as expected. So that’s, I think, the analyst’s role in what we’re doing. Now what we’ve done for that role is exposed a number of capabilities that are specific to those people. We’ve exposed business process modeling, as Tom mentioned, we’ve exposed use-case modeling, so we’ve tried to minimize the amount of UML and BPM notation so that we don’t inundate everybody with too much complexity. So they’re basically building a role-specific workspace or cockpit facilities that they would most likely use.
We then also have the Together Architect 2006 offering which is targeting the architect. The architect is a hard role to kind of pinpoint because, depending on the organization, it could really lead to a number of things, and, Tom, certainly step in here when you have comments. But the architects themselves could be someone responsible for developing the high-level architectural framework that a collection of systems or applications would be based on. Their concern would be more around developing a framework that’s adaptable, something that’s resilient over time,
so that what they develop over the next quarter or couple of quarters is something that’s going to be cost-effective to manage 5 years, 10 years, 20 years down the road. For an IT organization, that’s critical. Many systems could be put in place and be run for 20 or 30 years, so, the architecture that the team leverages and uses is really paramount to driving the success of that application over time. So, again, they kind of bridge the requirements world, the analysts world and the developer’s world and have to be able to take the requirements that were put forth by a set of IT analysts or system engineers and develop the high-level framework that the application should adhere to.
Then we look at the developer team. The developers are those guys that are kind of left at the end who many times feel that they’ve got to do the heavy lifting. They’ve got to take this huge set of requirements, this unrealistic schedule, and basically develop an application and deploy that in a way that can be utilized by the operations team or be imbedded into a device that’s put on the marketplace for sale. So they really need to have a certain set of capabilities to allow them to improve their productivity in the context of their job. And, again, today developers are very code-centric. They want ways and facilities to help them visualize what they’re doing so they can be assured that the code they’re writing, from a design perspective, is being done in a way that follows best practices and is in compliance with just basic good software practices. So, that’s how we’ve kind of broken up some of those facilities. Maybe Tom can share some of the specifics in each of those, and how the capabilities in Together maps to those roles.
Tom Gullion: Sure. So, the architect I’ll pick up first. There’s simply, as Mark mentioned, many breeds of architects, and I’m sure there are many architects out there listening at the moment. Certainly we are providing many up front design features. We’re having UML 2 and UML 1.4 as design language-neutral projects. This is somewhat new territory for Together as a product, so, we’re basing on the Live Source approach of the past. We feel like we’ve got that right. Definitely we are acknowledging that there are times and instances, especially with MDA, when you want to create a platform-independent model, and this is the proper way to do that. We’re now addressing that architect that wants to be independent of the platform and is much more interested in creating elegant and robust architecture. But then there’s no reason that you couldn’t continue to use Together Architect just as we historically have done and this is where we typically do it internally as well, in that the values of Live Stores still apply. The model is the code, the code is the model, there’s nothing wrong with that approach, and we certainly recognize that there are many architects who still value that very thing.
So we are providing an open, less rigid approach to developing software. We certainly recognize that there are many ways to do it, and we’d prefer to remain somewhat agile in the way we develop our tools so that we can let our customers take off the hand-cuffs and just get to work and do things that they need to do. So, many of our ancillary features, obviously metrics and all that, our extensible patterns, our extensible documentation generation, are completely customizable. Even code generation and the transformation…it’s a wide-open engine that anyone could use and leverage all the benefits of that. So, we’re really trying to respect the individuality of the different ways people work. I think that the architect is the one core piece that’s there. Many of our customers are saying, “Well, Yeah, but, I’m sort of a super-developer where part of my day I’m spending on architecture…’ and all that, but there’s no reason that, using the perspectives included in the product, you can’t just swap back and forth as you need to do.
John Kaster: OK, that’s helpful because we’ve been talking pretty high-level so it’s good to have some of the details on what we’re going to be supporting with Together 2006 as well.
So, obviously you’re at JavaOne and in a Java mindset this week, but what about most of the world, the heterogeneous environment that mixes Java and .NET? What are you doing to support that type of business organization?
Marc Brown: I think that’s actually a strength of Together and it’s a strategy for us. A key strategy for us going forward is to be able to support those organizations which are developing a mixture of different types of applications, or a mixture of services. In fact, in talking with many enterprises today, and if you look at the data we see and the data we hear from our customers, they are almost all of them about half and half. About half are doing .NET development, there’s half of the project that’s Java-based, and what was a little shocking for some of us at Borland is, in many instances, single projects, and we’ve heard this from about 30% of our customers, many of those customers actually have a single project with mixed components – some of those components being .NET-based, and some of those being Java-based. What we are doing on the Together side is providing that common framework from a role-centric perspective to allow organizations to basically target the .NET or the Java platforms really effectively both ways. The analyst capabilities that are provided by the designer product and the architectural capabilities can be applied independent of the platform that’s being targeted. We’ve recently announced Together Designer and Together Developer 2005 for Visual Studio. We really feel it’s critical for Borland to provide enterprise customers and customers in general the choice to be able to have these modeling capabilities in their own specific shells. So, whether they want to use Visual Studio or they want to use Eclipse, we want to give them the choice and then provide the modeling facilities to help them facilitate the development efforts on each of those respective platforms. Anything to add there, Tom?
Tom Gullion: No, I think you did a great job!
John Kaster: Heh, well, that must be why you guys work together. (laughs)
Marc Brown: (laughs)
John Kaster: Speaking of Eclipse, could you tell us what Borland is doing around Eclipse now?
Marc Brown: Yes. I think from a high level there’ve been a number of announcements that Borland has put out recently that really talk about the overall company strategy on Eclipse. I think it gets back to the point I just made about customer choice.
We’ve found, and we’ve seen, that as Eclipse has evolved over a good number of months, there’ve been a number of customers who see a lot of value in what the Eclipse platform offers. It really provides for them a common platform that provides a lot of extensibility capabilities. So they now have the ability to take various capabilities from different vendors, put those together, and really unify their client-side infrastructure. It also allows them the ability to extend with their own proprietary capabilities that they may need within their organization to unify that together within one client-side infrastructure.
So, Borland is just basically following our existing strategy by providing our customers with a choice while we are looking at moving a number of our capabilities. So, this is nothing new to Together. Together has been on the Eclipse platform for some time. We’ve had an addition available there for some time now. But, if you look across the board, all of our ALM capabilities are now accessible through the Eclipse platform.
So, if you’re an architect and you’re working on architectural aspects you have the ability to get to your version control system within Eclipse. You have the ability to get to the various requirements that were put and stored in your requirement repository, such as Star Team and CaliberRM. We see this trend across the board.
A lot of people have asked what we’re doing around JBuilder. JBuilder is certainly a well-known product for the Java community. It’s something that’s going to continue on as-is, but, also we’ve got an initiative that we’ve announced recently called Peloton that really is our direction for bringing the JBuilder capabilities into the Eclipse framework. So, next year you’ll see more of these things really bringing the best of breed capabilities that Borland’s had across the ALM suite and moving these things in a very unified, well-integrated way into the Eclipse framework. I do think that we’re trying to do this in a very agile way so that customers can pick and choose the capabilities they need and then plug them into the Eclipse framework.
John Kaster: That sounds pretty exciting…
Marc Brown: I think it’s very exciting, and, again, it’s something that we think is strategic to do both on the Eclipse side and it’s something we’re doing also on the Microsoft side.
John Kaster: Alright, I have a question from another user. He’s actually a fan, and he wants something from us, so, it’s a question and a statement: ‘Will this new version introduce new pricing as well? The previous version was too expensive and we really needed a Java version on the price level of the Visual Studio version.’ Do you have any information on pricing yet?
Marc Brown: I can talk about that. The Together 2006 offering, the family itself, will be released in Q3 of this year. Pricing itself is still being discussed, but, certainly we’d like customer input. So, if we’ve got people out there on the chat session who have specific comments or inputs on what they’d like to see done, certainly have them bring it into BDN and we’ll take those inputs into our thinking. But, pricing itself, though, is still being discussed, still being determined, and we don’t have the pricing details worked out yet.
John Kaster: OK, great, thanks!
Tom Gullion: But can we hint? We are breaking the product into specific roles, so one can expect that Architect will cost significantly more than Analyst or Developer.
Marc Brown: That’s correct.
Tom Gullion: So, I think we’re meeting you half-way with that.
John Kaster: OK.
Marc Brown: That’s correct. Good point, Tom.
John Kaster: Fair enough. So, this is one of my questions because I’m always somebody who’s looking ahead to the future: What are future roles that you see Borland visualizing?
Marc Brown: You know, I think there’s a huge, wide array of very exciting things that Borland’s looking at. Looking back at something I briefly alluded to in the chat session: How can we use visualization across the board throughout the ALM to better aid each role within a development team to do their job more effectively? And, again, we are looking at a variety of things - whether it be more automated ways to automate and, maybe, transform requirement text into visualization. Can we take X today, that’s a requirement, and generate an activity diagram to ensure that the textual requirement is complete? Does it make sense? Is there ambiguity in the requirement that we’d like to flush out and really eliminate before that hits the downstream activity that causes defects and basically IT wait? So there are a number of things that touch on each of the specific roles.
We’re also looking at some other technologies that Tom may want to chime in around. How can we simulate some of these things from a business process perspective? How can we simulate some of the application models? And so forth. Maybe Tom wants to jump in and talk about some of the exciting technologies that we may be looking at that will be certainly addressing across each of those three roles…
Tom Gullion: Sure. Some of the really consistent customer feedback that we’ve gotten around the roadmap is that they’d like to be able to customize on roles. So, that’ something that we’re looking into. It’s a rather complicated little endeavor to pull off, but, it’s certainly something that we really value, that we’d like to be able to do, because everyone’s definition of developer, architect, or analyst seems to be totally different. Even with an implementation of a named process you get wide variations. So, that’s certainly something that we’re going for.
As Marc was just talking about, it’s really cross-cutting from a different perspective on products. Instead of just building features sets, I prefer to think of it, perhaps, as capabilities that cross all those roles. What Borland and the ALM message were trying to work around were these hard edges between point products and, oftentimes, products that were developed by other companies. So, you have a requirements management tool, and you have an IDE, and you have a modeling tool, and you have an app server, and something else that is managing change requirements. It’s a very difficult conglomeration to manage and to deal with. Many of the features that the ALM and that SDO, Borland’s little theme song, are now going to address are minimizing those edges, so, smoothing those things out. The next step for the logical evolution of that is, as Marc was talking about, intelligent use-case modeling, intelligence analysis modeling, business process modeling that can do things that can be consumed all the way across the lifecycle and certainly extending our metaphor of Live Source into the generative. Sometimes people misquoted or misheard it…the MDA approach as being very waterfall-ish, that I do a transformation change from a pie and it goes down lower levels of granularity and specificity. Certainly we have the intelligence, and we’ve been thinking about how to go back up the chain without having to suffer too much, which is presently the problem in most all MDA tools.
Marc Brown: Yeah, and I think one of the four things that John ought to say here is that what we’re looking at here is eliminating more and more of the manual steps that software organizations are facing. So, getting back to what Tom alluded to is that it’s just some intelligence that’s process-driven. Borland’s about choice. So, if you’re an agile shop, or if you’re a formal shop, bringing in some of that level of integration and automation so that if a particular activity is done, there may be a number of steps that happen for you that alert other particular stakeholders in your team about a specific activity or a specific artifact that’s been delivered. So, we’re looking at how to bring these things together in a more intelligent way and then also help automate those things that today are, unfortunately, just manually tracked.
John Kaster: You’ve been talking primarily about larger teams with multiple team members. What Together offerings would interest smaller teams of five or less, or even a single developer, or a single guy who’s the whole shop?
Marc Brown: I think Together itself is applicable to the smallest of shops, the one-person shop, or the large organization. And I think that, depending on the organizational size, there are going to be different needs. As you grow up in scale in enterprise size there are other factors that come in. You certainly need to be able to deal with geographically distributed teams. You need to figure out better ways for collaboration. So there are a number of capabilities that become more important for larger teams. The small team, whether it’s a team of one or five, I think are still looking for ways to be able to develop very adaptable applications. But, I think they are really looking for productivity increases. If you’ve got a single person shop, one of the best things you can do for them is make them more efficient with their job. So, I think that things that Together will offer are transformations, frameworks out of the box that really help them to be more efficient at doing the job at hand. And there are other things we’ll be looking at - other frameworks that may apply to a specific industry that may be applicable to bring into the tool to help kick-start activities for these small shops who would like to have a lot of that glue coat, or a lot of that plumbing, just done for them, and then allow them to plug in their own specifics and really allow them to deliver more efficiently.
John Kaster: OK, thanks. Tom, if someone is looking at getting into modeling and taking advantage of Together’s technology, do you have a quick crib sheet, or bullet points, you could share that would help people decide where to start with their purchase for Together? And what things they should be looking at first? If somebody is totally new to modeling and audits and metrics, where should they start?
Tom Gullion: At this moment I’m crafting a whole set of demos which is all about Together Architect Development 6 and related releases. So, if you could wait just a couple of weeks, then those will be up on the website and you can just check’em out. I think the most reasonable way to learn UML – it depends on your experience – but if you are coder, a developer, take your favorite open source project, reverse engineer it in Together, and have class diagrams drawn for you. Generate some sequence diagrams, run audit metrics against it, take notes with all the things you read in Joshua Block’s books, and see them automatically discovered in your code or someone else’s code, preferably someone else’s code so you can laugh louder.
John Kaster: Heh…
Tom Gullion: But, that’s always been the best place to start. We used to brag about that at Together Software. If you knew one, you could learn the other – if you knew Java, you could teach yourself UML, and if you knew UML you could teach yourself a target language just by watching Live Source do its thing.
John Kaster: OK, great! That sounds like a great way to start. It’ll be interesting and fun while you’re learning.
Tom Gullion: Yeah, exactly.
John Kaster: Alright. Well, we don’t have any further questions in the chat, so, I don’t know if you guys have any other wrap-up that you’d like to provide? We’re almost out of time anyway…
Marc Brown: No, but, I think this has been a very good session. I think if anybody on the chat session has further questions, feel free to ping Borland. We certainly are here. We want to hear from customers, we want to hear from users, and we really want to understand more of their experiences. I do think that, just in summary, Together 2006 is a really exciting launch. As I mentioned in the beginning of the chat session, it really brings together many of the best of breed capabilities that Together has offered for some time and combines them with a whole host of new compelling capabilities that touch on new markets, new areas for us, like the business analyst with business process modeling. So, we certainly like to hear from customers. We like to hear their thoughts on what they’d like to see from modeling going forward. What do they expect from Borland and where would they like to see modeling go in the future? Anything to add there, Tom?
Tom Gullion: I think the future is in the hands of the product. To experience the reality of MDA is sometimes as simple as just firing up the tool that does it and seeing how that thing works. It’s very easy to have many doubts about MDA in general. Many people very close to MDA expressed huge doubts about it, but, there are very valuable bits and pieces of it that could be applied to any context or any modeling methodology. So, I invite you to become part of the field test that’s going on now, or download the eval when it hits the website later in August and experience some of these features and try it out for yourself.
John Kaster: Alright, thanks! If you have visual questions that were not answered in this chat, feel free to email them to Anders Olsen, David Intersimone, or John Kaster. You can even comment on one of our blog entries to reach us if you don’t have our email addresses. Remember to check Events Central for announcements of additional chats and other events of interest to Borland customers. This replay will also be available shortly so you can share the playback with anyone who missed this chat. Thank you very much for your time and interest and we hope you found the chat valuable. Tom and Marc, thank you very much for spending time with us today.
Tom and Marc: Thank you!
John Kaster: And Anders, thank you very much for making sure the chat keeps running. Bye everyone, talk to you next time.
Server Response from: ETNASC01