A wise Manager once told me... actually told me several times that "It's all about the data." He had been in corporate Information Technology for 20-some years and now led a team of DBA's and Data Modelers, so may not have been the most objective source.
As Business Analysts, we bridge the sometimes scary gulf between a customer and a development team. I say sometimes, thinking of those occasions when the developers were all too eager to code something, anything, when the customers had just begun to think about the problem.
Sometimes, it seems like a developer may have a hidden agenda; some program he or she has wanted to code and is just waiting for a budget to write that thing. That's the BA perspective; I've heard the developers express frustration over waiting weeks for documentation... and in the meantime having no available charge codes... and then receiving wildly inaccurate specifications. After developing to those, it was of course up to them to implement the necessary design changes on their own time and budget.
We Business Analysts can make things better for both groups we serve by getting the requirements correctly and quickly. One key factor for accomplishing that is understanding that requirements are more than function lists. We sometimes have to tweeze out business rules... even recommend that the application allow for evolving changes. And we certainly have to get a handle on the data.
A Data Architect or Data Modeler may join us on the team. That's fine, as long as we can stay in tandem with them. Many have highly refined skills in drawing third-normal-form diagrams, then adroitly changing them into physical databases.
When we work with them, our responsibility as BA is simply to be sure they have opportunity to draw out all the necessary nouns from our mutual clients. Those nouns become entities and attributes, and later become tables and columns in the database supporting the technology solution our clients seek.
If you know a bit about third normal form and data modeling, you might want to draw a preliminary Conceptual Data Model (CDM) or more detailed Logical Data Model (LDM). If you have license to such diagramming powerhouses as Embarcadero ER/Studio or CA ERWin, you can quickly draw an impressive Entity Relationship Diagram (ERD). If you really want to be helpful, include definitions, relationship names and data types with those diagrams. Otherwise, your partnering Data Architect may cry, "Where's the metadata?"
I am biased towards ER/Studio because it draws beautiful diagrams so easily and even will untangle all the relationship lines for you with one click. ERWin now does that, but with far fewer options and not so elegantly.
Recently, I needed a data modeling tool for another machine and another client and had no budget. Fortunately, Dan Horn had posted a very handy chart online, listing 65 products, each with a link to the vendor website, a price quote and comments. Prices range from free to $14,000 with many in the $100 - $200 range.
After looking through that chart, I settled on Power Architect. It wasn't as easy to learn and use as the $2K+ enterprise tools I had used before, but it did the job. It did at least the part of the job where the model was drawn and then forward engineered into a database. The other part of the job was meetings with the client to review iteration after iteration of the paper diagram until I really had drawn the data elements they needed.
The work was all very much in line with what a BA must do. And in that case, it was all about the data.
As Business Analysts, we bridge the sometimes scary gulf between a customer and a development team. I say sometimes, thinking of those occasions when the developers were all too eager to code something, anything, when the customers had just begun to think about the problem.
Sometimes, it seems like a developer may have a hidden agenda; some program he or she has wanted to code and is just waiting for a budget to write that thing. That's the BA perspective; I've heard the developers express frustration over waiting weeks for documentation... and in the meantime having no available charge codes... and then receiving wildly inaccurate specifications. After developing to those, it was of course up to them to implement the necessary design changes on their own time and budget.
We Business Analysts can make things better for both groups we serve by getting the requirements correctly and quickly. One key factor for accomplishing that is understanding that requirements are more than function lists. We sometimes have to tweeze out business rules... even recommend that the application allow for evolving changes. And we certainly have to get a handle on the data.
A Data Architect or Data Modeler may join us on the team. That's fine, as long as we can stay in tandem with them. Many have highly refined skills in drawing third-normal-form diagrams, then adroitly changing them into physical databases.
When we work with them, our responsibility as BA is simply to be sure they have opportunity to draw out all the necessary nouns from our mutual clients. Those nouns become entities and attributes, and later become tables and columns in the database supporting the technology solution our clients seek.
If you know a bit about third normal form and data modeling, you might want to draw a preliminary Conceptual Data Model (CDM) or more detailed Logical Data Model (LDM). If you have license to such diagramming powerhouses as Embarcadero ER/Studio or CA ERWin, you can quickly draw an impressive Entity Relationship Diagram (ERD). If you really want to be helpful, include definitions, relationship names and data types with those diagrams. Otherwise, your partnering Data Architect may cry, "Where's the metadata?"
I am biased towards ER/Studio because it draws beautiful diagrams so easily and even will untangle all the relationship lines for you with one click. ERWin now does that, but with far fewer options and not so elegantly.
Recently, I needed a data modeling tool for another machine and another client and had no budget. Fortunately, Dan Horn had posted a very handy chart online, listing 65 products, each with a link to the vendor website, a price quote and comments. Prices range from free to $14,000 with many in the $100 - $200 range.
After looking through that chart, I settled on Power Architect. It wasn't as easy to learn and use as the $2K+ enterprise tools I had used before, but it did the job. It did at least the part of the job where the model was drawn and then forward engineered into a database. The other part of the job was meetings with the client to review iteration after iteration of the paper diagram until I really had drawn the data elements they needed.
The work was all very much in line with what a BA must do. And in that case, it was all about the data.
Comments