One of the most exciting benefits of Agile Integration Software is the ability to dramatically streamline the analysis and other processes around designing and implementing integration solutions. If RAD (Rapid Application Development) is fundamental to the essence of the software, then it is natural that a new genre of best practices will emerge leveraging the agility of the software.
Enterprise Enabler® has "fuzzied" the lines between the classic steps of analysis, design, development, testing, and deployment. I'd like to share a couple of ways that it is changing the way teams develop integrated solutions.
Analysis Workshops replace Specs. "What?!!!," you say. "That's heresy! No self-respecting IT department would eliminate writing specs!" Ok, so hear me out. Everyone knows that the most time consuming, messiest, most unpleasant part of the whole project is defining the specs, especially the mapping specs. Well, not just defining them, but documenting them, running them by everyone for approval, re-working them, running them by everyone for approval (and so on), and even worse, keeping them up to date over time. Wouldn't you love for that whole exercise to be history, and yet to be able to get the exact current definition any time? With Enterprise Enabler, the specs are synonymous with the solution.
Here we go. You're in a conference room (or web meeting) with three other people, Tom, Dick, and Jane. You are the project manager or an analyst, or even a programmer. You're on the keyboard with Enterprise Enabler's user interface projected on the screen. With you, remotely or in the room, are the three business analysts that really know their systems' data and how it is used. Think how many questions can be resolved in a very short time if these key people can discuss what they require while you build it!
Pass the doughnuts around while we define the big picture of the integration we are solving. Jane is the expert on the destination application, "D," so in my book, she's the boss. After all, the destination's the only the application that cares about the data in an integration. Tom owns source "A" and Dick owns source "B." You pull up the template builder to define the metadata for the appropriate data from "A." Tom points you to the instance of the system that you will be working with and you show him the schema as he indicates what is of interest from his app. Then you do the same with Dick, and then with Jane for the destination. She has indicated what needs to be populated. You go to the mapper and everyone can see on the left all the fields from both sources and on the right, the fields to be filled. First Dick and Tom help you define the cross-application relationship by identifying the appropriate key fields, while you drag and drop them to create the virtual relationship. Now you continue to work with these experts to build and test the data mapping en situ. Tom discovers he left out a couple of tables he need, so you bring up the template and add the tables, and you're back in business. You run the map through and let Tom, Dick, and Jane discuss the nuances of whichever data are not obvious until it is correct. You're done, maybe even before the doughnuts are finished. And the programmed mapping will always match exactly what you see on the screen. When Jane changes her mind or Dick's application has updates that change the schema, you simply go in an reflect it in a couple of minutes.
Integration will become a set of well defined and productive workshops with all the right people, wherever they are. You'll only reminisce about the old days and how difficult it was to get the specs from each expert, document them, and go from one to the other, changing and updating, and then not being able to find the specs document to be able to keep it up to date. Remember when the programmer would discover a problem with the specs and would fix the code, but the change never got back to the specs? Ah... for these headaches to be history!
No comments:
Post a Comment