This week was interesting. The place at which I spend many minutes had a disaster. There was an explosion below the street, causing one unfortunate soul incredible burns, and an entire block the loss of power. Some residents nearby were without heat for over twenty four hours. That's not good if you live in a winterious place.
The place I spend many minutes were incredibly equipped to deal with the disaster. They have a DRP appropriate for their size and focus. We had PC's to work on in another facility within 120 minutes. The PC's were not equipped with the software which most of us needed, but we were able to spend some minutes doing something productive in most cases. Two departments were sent home, as there were only so many PC's, and only so much spare space.
In contrast, there were vandals who were also disgruntled employees of a large tenant company in the same building in which I spend many minutes. They decided to use the fire hoses on the top floor and play games by filling the stair wells with water to express their discontent. Their employer decided to only pay them for a small portion of the day of pay they lost for that same electrical interruption. With only four weeks before Christmas, and being paid only marginal amounts over minimum wage, can you see the point of aggravation?
Now all companies affected must pay an insurance company to clean up their messes in offices that span the building, and the insurance company gets to collect several premiums because all tenants affected must pay, and the restoration company will pretend that they can do all of the work and make things right. And, next year and for the next five, all of these affected companies will get to pay some rich insurance companies extra premiums for bad experience.
Do I sound facicious here? I definitely am being so, as I have been the victim of water damage once and had to use that same restoration company. Believe me - you don't ever want to encounter this so go right home and make sure you have the bullet-proof hoses on your washing machines, buy a water beetle and hook it up to your alarm system, and definitely ensure that the little birdies outside aren't making nests in your bathroom vents so that vents are forced open and pipes may freeze.
Also - I am facicious because I have seen that tenant who employs the vandals exploit their staff, vendors and suppliers. If they would have coughed up the dough to pay a full days' pay, or had a disaster recovery plan to enable the workers to do something else productive, none of that would have happened.
I continue my attitude as I had dinner with colleagues the day following the incident. We all shared work experiences and customer stories of the places in which we are spending many minutes. I found it humourous, then aggravating that one was spending two years of a client's money creating a DRP and they still didn't really get the point. Most companies who embark on DRP's shouldn't really call them that. They should call them their "how to get my technology all up and running". Most have limited budgets and cannot begin to create a plan to recover everything. What about the business?
Why bother? Is everything that important? Is the little system that your company uses to catalogue the books in your IT library, or the research reports employees create when they really should be doing something else important? Yes - these things are great to have, if you actually had a reason for creating them, but is more than a back up really that important.
You knew I'd eventually get back to Architecture - I always do. I eat sleep and breathe the stuff. A great EA can completely replace the need for the kind of DRP these companies think they need. If your business functions are well (and I don't mean completely) documented, and you know which ones you need to keep the $ rolling through the doors, and what their priorities are, why spend the equivalent of three or four peoples salaries in a year paying a consultant or two to write you a plan to recover everything you have as fast as you can? Believe me, some stuff can wait, and a backup of the data is likely sufficient.
If you need to get help on a DRP plan, I suggest you find someone who understands the concept well. If you want to completely document your technical architecture, good for you, but tying it to the recovery plan will only delay the process. The two should be separate endeavours and it should be pretty easy to figure out which one comes first. Key word is should.
There - the satiristical side of me. I promise to behave next time out - this was a tough week to feel productive.
Friday, December 02, 2005
Thursday, November 17, 2005
A Journey to the High Road
I’ve been asked over and over how I became an I.T. Architect. I always hesitate, and say “well…” More often than not, I get into the long stories about my university degrees and my varying path in life and career. The short answer is “I changed careers multiple times within the field of I.T.”. The long answer is experience.
The I.T. Architect is a technologist, a leader, a consultant, a strategist, a politician, a writer and an artist. Yes, I threw that last one in for humor, but I get countless “way to go Picasso” comments, when I’ve helped a client with a modeling conundrum, or even cleaned up after a whiteboard session and converted our thoughts into something readable, tangible and electronic.
As a technologist, the architect must specialize in technology, information or applications if he or she is a domain architect “Data Architect, Information Architect, Technical Architect, Application Architect, Software Architect, etc.” I must understand the pertinent technologies, plus have an in-depth understanding of the entire domain. Learning the key issues around my domain and knowing the Best Practices and key standards, methods, processes and techniques key to being a good practitioner is also necessary.
I consider all the matters at hand, and analyze the tradeoffs. I get to “play” by prototyping and experimenting with technologies, taking various system viewpoints when drawing up models and then testing them later with prototyping tools. I am fortunate enough to keep tabs on the “what’s new” in technology, and follow the trends and create roadmaps for the future. Mapping out where you want to go is always done in a more positive light than where you have been.
As a not such an enjoyable task, the Architect must document and present their findings to incredibly critical groups of people. Everyone has an opinion, and at the end of the day, even with a little bickering and bantering, it’s all a good thing. I’ll take that over dead silence any day. I get to do the investigations, and create the future, so I must be tolerant of changing my work on an ongoing basis to accommodate the opinions of many, while maintaining my initial vision.
The I.T. Architect is a technologist, a leader, a consultant, a strategist, a politician, a writer and an artist. Yes, I threw that last one in for humor, but I get countless “way to go Picasso” comments, when I’ve helped a client with a modeling conundrum, or even cleaned up after a whiteboard session and converted our thoughts into something readable, tangible and electronic.
As a technologist, the architect must specialize in technology, information or applications if he or she is a domain architect “Data Architect, Information Architect, Technical Architect, Application Architect, Software Architect, etc.” I must understand the pertinent technologies, plus have an in-depth understanding of the entire domain. Learning the key issues around my domain and knowing the Best Practices and key standards, methods, processes and techniques key to being a good practitioner is also necessary.
I consider all the matters at hand, and analyze the tradeoffs. I get to “play” by prototyping and experimenting with technologies, taking various system viewpoints when drawing up models and then testing them later with prototyping tools. I am fortunate enough to keep tabs on the “what’s new” in technology, and follow the trends and create roadmaps for the future. Mapping out where you want to go is always done in a more positive light than where you have been.
As a not such an enjoyable task, the Architect must document and present their findings to incredibly critical groups of people. Everyone has an opinion, and at the end of the day, even with a little bickering and bantering, it’s all a good thing. I’ll take that over dead silence any day. I get to do the investigations, and create the future, so I must be tolerant of changing my work on an ongoing basis to accommodate the opinions of many, while maintaining my initial vision.
Monday, October 31, 2005
Strange But True
Boo!
Did you survive the EAC? I am almost caught up on my sleep - just a two hour time change plus flight plus daylight savings time and I've turned into Rip Van Winkle. I'm sure I'll be caught up by tomorrow, but still have lots of miscellaneous thoughts swirling around in this head.
About 18 months ago, I gave a presentation at a Canadian Information Processing Conference, titled "Enterprise Architecture - What Have You Done for me Lately?" It was all about Enterprise Architecture Maturity, and convincing folks that EA was far more that hanging up the Framework and letting the holes and gaps emit light.
This past week, I heard so many points over again that I'd made myself and I wondered how this was possible. I guess it's just that this stuff makes sense to those who live and breathe it and there are just so many ways to say it. This week I heard all about the "value in the arrows", or perhaps that's how I perceived it as it was a scribble I'd noted in the presentater's note copy that I returned with.
My speech on EA maturity was about adding the linkages as that was where the value was. I guess this is essentially the same. It's about creating the relationships to add Architecture value. Listing all of the components, technology and hardware only has so much value. It's when you start to measure it and create the numerous amounts of relationships that you see value.
Something else, strange but true, but I noticed that three of the six panelists on the "Ask the Experts" session on the last day were Architect's who were former Data Architects, or had written columns in data magazines I'd followed in the 90's. Well - that's where my roots are and I wondered if all Information Architect's had evolved into EA's. I mean - we were the only ones religious about models in the 80's and 90's, so it probably makes sense now, doesn't it? Boxes and arrows, lines and boxes - whatever it takes to provide value - it's the way we think and there is no changing that.
My last "Strange but true" thought for this Hallowe'en night - thought it was odd how this year's new comment addition to John Zachman's otherwise similar message was that he'd had a complaint about his slides by the conference coordinator. Apparently he'd pointed out to her that he had to continue to return with the same old slides because he had the same old thing to say, and that no one listened to him anyways.
Now - how can one person run around for thirty years trying to get everyone to listen and to follow. Mr. Zachman obviously is tenacious, as he has never given up because he believed. And by the numbers and passion I saw around this subject at this conference, I believe that he will soon be able to retire a very satisfied person.
Well - enough blogging for now. Time to hide the leftover candy and put away the pumpkin.
Boo!
Did you survive the EAC? I am almost caught up on my sleep - just a two hour time change plus flight plus daylight savings time and I've turned into Rip Van Winkle. I'm sure I'll be caught up by tomorrow, but still have lots of miscellaneous thoughts swirling around in this head.
About 18 months ago, I gave a presentation at a Canadian Information Processing Conference, titled "Enterprise Architecture - What Have You Done for me Lately?" It was all about Enterprise Architecture Maturity, and convincing folks that EA was far more that hanging up the Framework and letting the holes and gaps emit light.
This past week, I heard so many points over again that I'd made myself and I wondered how this was possible. I guess it's just that this stuff makes sense to those who live and breathe it and there are just so many ways to say it. This week I heard all about the "value in the arrows", or perhaps that's how I perceived it as it was a scribble I'd noted in the presentater's note copy that I returned with.
My speech on EA maturity was about adding the linkages as that was where the value was. I guess this is essentially the same. It's about creating the relationships to add Architecture value. Listing all of the components, technology and hardware only has so much value. It's when you start to measure it and create the numerous amounts of relationships that you see value.
Something else, strange but true, but I noticed that three of the six panelists on the "Ask the Experts" session on the last day were Architect's who were former Data Architects, or had written columns in data magazines I'd followed in the 90's. Well - that's where my roots are and I wondered if all Information Architect's had evolved into EA's. I mean - we were the only ones religious about models in the 80's and 90's, so it probably makes sense now, doesn't it? Boxes and arrows, lines and boxes - whatever it takes to provide value - it's the way we think and there is no changing that.
My last "Strange but true" thought for this Hallowe'en night - thought it was odd how this year's new comment addition to John Zachman's otherwise similar message was that he'd had a complaint about his slides by the conference coordinator. Apparently he'd pointed out to her that he had to continue to return with the same old slides because he had the same old thing to say, and that no one listened to him anyways.
Now - how can one person run around for thirty years trying to get everyone to listen and to follow. Mr. Zachman obviously is tenacious, as he has never given up because he believed. And by the numbers and passion I saw around this subject at this conference, I believe that he will soon be able to retire a very satisfied person.
Well - enough blogging for now. Time to hide the leftover candy and put away the pumpkin.
Boo!
Thursday, October 27, 2005
The Games Continue
Here I am again, bleary eyes but wanting to share all from this year's Fall EAC. I have so much to share, and tonight will just have to be a summary. I catch the red eye in 6 hours, and suitcases still have to be filled - you know the drill.
This year was a little different. More keynotes, but fewer messages. The last one was fabulous, so all is not lost. John Zachman has finally admitted there is no silver bullet and still maintains that one day we will all wish we'd filled his magic framework. I'm not arguing but there were more that agreed with me this year that feel practicality is a virtue.
The conference offered two panel sessions this year, and not as a keynote. Great touch - heard some great things except for a 30 minute drone about certifying EA's. There is much passion about this, but hard to get excited after listening to it around the CIPS ISP. Sort of boring and so far from reality. Perhaps we should work on a common vocabulary as I hear more acronyms that you can imagine for what goes on in the Business Architecture. Reminds me of the early nineties when modeling tools first entered the scene and with a flick of a button you could create a new flavour of the day - all of which equated to a logical or process flow diagram.
There was an increase in both the sessions and numbers of folks who attended the "Build" as well as "Run" Sessions. Good for you! This just means that there are the masses attending the Plan, meaning we still don't have anything done yet.
The most common question I heard all week was "how do we know when we've modelle enough?". Various answers - deserves a blog onto it's own - but all it means is that we're progressing.
Well - have to type more tomorrow - 4 bells come early and I will take a break from this little stanza.
Happy Architecting and Happy Friday!
Sharon
This year was a little different. More keynotes, but fewer messages. The last one was fabulous, so all is not lost. John Zachman has finally admitted there is no silver bullet and still maintains that one day we will all wish we'd filled his magic framework. I'm not arguing but there were more that agreed with me this year that feel practicality is a virtue.
The conference offered two panel sessions this year, and not as a keynote. Great touch - heard some great things except for a 30 minute drone about certifying EA's. There is much passion about this, but hard to get excited after listening to it around the CIPS ISP. Sort of boring and so far from reality. Perhaps we should work on a common vocabulary as I hear more acronyms that you can imagine for what goes on in the Business Architecture. Reminds me of the early nineties when modeling tools first entered the scene and with a flick of a button you could create a new flavour of the day - all of which equated to a logical or process flow diagram.
There was an increase in both the sessions and numbers of folks who attended the "Build" as well as "Run" Sessions. Good for you! This just means that there are the masses attending the Plan, meaning we still don't have anything done yet.
The most common question I heard all week was "how do we know when we've modelle enough?". Various answers - deserves a blog onto it's own - but all it means is that we're progressing.
Well - have to type more tomorrow - 4 bells come early and I will take a break from this little stanza.
Happy Architecting and Happy Friday!
Sharon
Tuesday, October 25, 2005
Let the Games Begin
This week will be special - I get to spend a week with other architects at the DCI Enterprise Architecture Conference. Ok - I'm weird - I love to talk about this stuff, but this is like sending a Gambling Addict to a Casino - oh wait -that's where I am!
Never mind - I tried those slot machines and any way you slice it - you will lose. Bet the farm on EA and you will win. It's exciting - I get to talk to some of the smartest people around about the coolest projects, and learn at the same time. Today was just the "opener" - a new CD to peruse, and some sessions to pick from, as well as a vendor presentation.
Now - I might be biased, but no matter how many vendor presentations you attend, you have to agree - there are some gems of info amongst them. Today I listed to Telelogics's presentation on what they have to offer the Architecture Tools space. Always interesting, as the EA's that I know are incredibly demanding and always want one more thing that no tool does. This was an interesting approach - buy the pieces you need to fill your gaps, intelligently - like an EA would do it themselves.
Now - don't get me wrong - I'm not condoning their tools - if you know me - I don't do that. But I like to see the good or best of breed where credit is due, and it looks like they've approached it in another manner. I'll be interested in visiting the vendor fairs tomorrow to see if I can see at a glance where the rubber meets the road.
If not, I'll definitely tell you to save your money. If we're lucky - it'll make the hopeful list and give us Architects a chance to automate some of our work.
Until tomorrow
Sharon
Never mind - I tried those slot machines and any way you slice it - you will lose. Bet the farm on EA and you will win. It's exciting - I get to talk to some of the smartest people around about the coolest projects, and learn at the same time. Today was just the "opener" - a new CD to peruse, and some sessions to pick from, as well as a vendor presentation.
Now - I might be biased, but no matter how many vendor presentations you attend, you have to agree - there are some gems of info amongst them. Today I listed to Telelogics's presentation on what they have to offer the Architecture Tools space. Always interesting, as the EA's that I know are incredibly demanding and always want one more thing that no tool does. This was an interesting approach - buy the pieces you need to fill your gaps, intelligently - like an EA would do it themselves.
Now - don't get me wrong - I'm not condoning their tools - if you know me - I don't do that. But I like to see the good or best of breed where credit is due, and it looks like they've approached it in another manner. I'll be interested in visiting the vendor fairs tomorrow to see if I can see at a glance where the rubber meets the road.
If not, I'll definitely tell you to save your money. If we're lucky - it'll make the hopeful list and give us Architects a chance to automate some of our work.
Until tomorrow
Sharon
Sunday, October 16, 2005
The Main Issue with Enterprise Architecture
I spend time weekly trying to think of "shareable" things I've done I can put up on the www.architectbootcamp.com to spread the wealth in creating more and better I.T. Architects.
I sat down the other day with a napkin and a pen, trying to list all of the issues I've heard clients mention or express concern about and thought these would be ideal subjects for blogs or newsletters.
Issue Number 1 - Getting Enterprise Architecture Funded.
If you have Mr. Sarbanes, or Mr. Oxley knocking on the door - you have already danced this dance. Executives fully understand the value of architecture, and you've likely got a good head start on a program and maybe even a plan.
If you were to say to a CEO "If you don't fund this project, it tells me you are not really serious about this business strategy" what do you think you'd get back in response?
If every time you were handed a new business initiative to "implement" - I mean - make all I.T. modifications or additions to support it, wouldn't it be great if the CEO also had budgeted a step for "update Enterprise Architecture and align I.T. with this strategy". Ok - so many of you are now leaving saying - yeah, right.
But what if you could prove to the executive, or demonstrate to them that each time they come to you asking for a strategy to be "IT-ized", the planning and development of it could be on a gradually reducing time line if you had architecture in place? Now we're talking. It's so hard, and you continually have to prove value. These are the reasons that EA is hard to justify - it takes doing it and proving it to show value, and you can't really do it or prove it until you've done it.
Not quite entirely true - you do components or pieces of it all of the time, usually by means of projects. What if you were to document the wins from those projects, and tie them to a framework, or lite view of framework to show you've been working on this all along. You might have a conversation to get this rolling about the possible benefits. An extra win might be in order if you happen to mention some of those times that the Executive was happen with I.T. results and demonstrate the Architecture components or efforts.
Happy Architecting,
Sharon
I sat down the other day with a napkin and a pen, trying to list all of the issues I've heard clients mention or express concern about and thought these would be ideal subjects for blogs or newsletters.
Issue Number 1 - Getting Enterprise Architecture Funded.
If you have Mr. Sarbanes, or Mr. Oxley knocking on the door - you have already danced this dance. Executives fully understand the value of architecture, and you've likely got a good head start on a program and maybe even a plan.
If you were to say to a CEO "If you don't fund this project, it tells me you are not really serious about this business strategy" what do you think you'd get back in response?
If every time you were handed a new business initiative to "implement" - I mean - make all I.T. modifications or additions to support it, wouldn't it be great if the CEO also had budgeted a step for "update Enterprise Architecture and align I.T. with this strategy". Ok - so many of you are now leaving saying - yeah, right.
But what if you could prove to the executive, or demonstrate to them that each time they come to you asking for a strategy to be "IT-ized", the planning and development of it could be on a gradually reducing time line if you had architecture in place? Now we're talking. It's so hard, and you continually have to prove value. These are the reasons that EA is hard to justify - it takes doing it and proving it to show value, and you can't really do it or prove it until you've done it.
Not quite entirely true - you do components or pieces of it all of the time, usually by means of projects. What if you were to document the wins from those projects, and tie them to a framework, or lite view of framework to show you've been working on this all along. You might have a conversation to get this rolling about the possible benefits. An extra win might be in order if you happen to mention some of those times that the Executive was happen with I.T. results and demonstrate the Architecture components or efforts.
Happy Architecting,
Sharon
Thursday, October 06, 2005
Just How Many Ways are there to do things?
I'm sure as many of you do, you reach home after a weary four days of work and are frustrated because your work seems to be one big giant conflict. You spend an hour and a half of a one hour meeting (notice that we only went over by 50%?) going back and forth and back and forth. You might get a turn with the magic white board markers, confident that once you play picasso, everyone will get it and the argument will be over.
Well - was I in a doozy today - I just sat and played the referee, as it was the role I was paid to play - I would ask questions like "What if you were to ..." and see what they'd say. At the end of the day, I took on another role - it was to say - something like "let's say there are two options - which would you prefer?"
Now we're getting somewhere - people are always better at pointing out fault with something concrete, rather than trying to come up with pieces of something or arguing about minute points.
If you get to play architect, this might be one tactful approach. Architecture is more about politics than it seems to be about technology. You can't just show up as a great IT polician and expect to be a good architect, but if you are a good architect, being tactful and a great politician sure helps.
So back to the dilemma at hand. Do you ever notice that at the end of one of these types of meetings you are down to two options? It's not that there are just two choices, but there are two that the group hasn't discarded and are willing to back. Pick one, see if it looks like swiss cheese, and then jump ship if it seems that it won't float your boat!
Well - was I in a doozy today - I just sat and played the referee, as it was the role I was paid to play - I would ask questions like "What if you were to ..." and see what they'd say. At the end of the day, I took on another role - it was to say - something like "let's say there are two options - which would you prefer?"
Now we're getting somewhere - people are always better at pointing out fault with something concrete, rather than trying to come up with pieces of something or arguing about minute points.
If you get to play architect, this might be one tactful approach. Architecture is more about politics than it seems to be about technology. You can't just show up as a great IT polician and expect to be a good architect, but if you are a good architect, being tactful and a great politician sure helps.
So back to the dilemma at hand. Do you ever notice that at the end of one of these types of meetings you are down to two options? It's not that there are just two choices, but there are two that the group hasn't discarded and are willing to back. Pick one, see if it looks like swiss cheese, and then jump ship if it seems that it won't float your boat!
Monday, September 26, 2005
The Architect Abstract
What came first – the solution or the data?
I’ve spent years in IT and no matter what I do, it keeps coming down to the data. As an Enterprise Architect, selecting a portal for a large financial company was an exercise to plan for technology that would support data in many areas.
As the years go by, Data Architects have become responsible for Web Site Content. Sadly, there are many folks out there on the Web who actually think this is Information Architect – yikes. (see my related article at Architect Boot Camp in the Information Architecture Section It is so much more than just content, although the Data Architect’s job has become so big when they have to figure out how this stuff is going to be stored and organized as well as designing custom databases for inhouse applications.
So when you are called upon to create a Solution Architecture – where do you start? The requirements is usually the first place, but often the requirements come out in the form of Data. Someone says “we have this sales information and we need to make it viewable and include the ability to create custom reports for our marketing managers.” So what do you do first? Do you create a data model? Do you pick technology to run it on? Do you choose the application technology you will use to create it?
Architecture is both a means of doing an inventory, linking and creating new stuff. The inventory in this case includes finding out if this data all lives in a database you can access directly, or whether or not you need to create a new one. It also includes an inventory check of the custom development and data warehousing technologies you have, as well as the interface technologies you have to bring them to the users.
What about security? Do you have that in place to present this information to the marketing team over the net in distant places? Or do you need to protect this stuff so Walmart can’t get it (just kidding – they are the favorite commercial villain, right next to Microsoft!).
How about resources – do you have anyone in your company who has done this before? Can you borrow someone who’s done it, or better yet, some application and resource who have done it and simply tweak it to get new data?
The longer you’ve been around as an IT Architect, the better you’ll get at recognizing patterns, inventorying them and picking them back up and dusting them off for a new solution. Ain’t life great? The best employees might also be the ones who try to do as little new work as possible!
I’ve spent years in IT and no matter what I do, it keeps coming down to the data. As an Enterprise Architect, selecting a portal for a large financial company was an exercise to plan for technology that would support data in many areas.
As the years go by, Data Architects have become responsible for Web Site Content. Sadly, there are many folks out there on the Web who actually think this is Information Architect – yikes. (see my related article at Architect Boot Camp in the Information Architecture Section It is so much more than just content, although the Data Architect’s job has become so big when they have to figure out how this stuff is going to be stored and organized as well as designing custom databases for inhouse applications.
So when you are called upon to create a Solution Architecture – where do you start? The requirements is usually the first place, but often the requirements come out in the form of Data. Someone says “we have this sales information and we need to make it viewable and include the ability to create custom reports for our marketing managers.” So what do you do first? Do you create a data model? Do you pick technology to run it on? Do you choose the application technology you will use to create it?
Architecture is both a means of doing an inventory, linking and creating new stuff. The inventory in this case includes finding out if this data all lives in a database you can access directly, or whether or not you need to create a new one. It also includes an inventory check of the custom development and data warehousing technologies you have, as well as the interface technologies you have to bring them to the users.
What about security? Do you have that in place to present this information to the marketing team over the net in distant places? Or do you need to protect this stuff so Walmart can’t get it (just kidding – they are the favorite commercial villain, right next to Microsoft!).
How about resources – do you have anyone in your company who has done this before? Can you borrow someone who’s done it, or better yet, some application and resource who have done it and simply tweak it to get new data?
The longer you’ve been around as an IT Architect, the better you’ll get at recognizing patterns, inventorying them and picking them back up and dusting them off for a new solution. Ain’t life great? The best employees might also be the ones who try to do as little new work as possible!
Monday, September 19, 2005
First Blog
Welcome to the Architect Abstract Blog Edition 1
The Start of ASolution - is it Data Architecture first?
Today I'm thinking about how important data design really is to solution design. I often wonder if our roots in Information Technology will always take over our thoughts - I used to work exclusively with data and moved on to Architecture. Now, when I work in the System Architecture space, particularly on design or solution, I revert to data - and often first.
We need to understand what the data will look like and what is needed before we can design. After all - information technology is about information and always about moving it around. We manipulate, massage, analyze and display it - what impact does it have?
Today I am trying to help clients come up with a new way to allocate files based on a bunch of business parameters. Over the years, they have bandaided the process, and morphed it based on many business needs that have nothing to do with the allocation itself. It was almost mind numbing to walk through the paths and rules that had been added over the years. I'd get
frustrated and start over and over going back through the data.
Eventually I thought "this is crazy - what are we really trying to do here, and what is the bare minimum of information we need?". Simplifying things brought clarity. After I weeded out all of the special cases, I found that the solution was rather simple - there were two basic methods, with a third method that could be applied to one of the first two based on a third parameter. Voila - done. Add a bit of history logging to enable lots of great reports on performance, volumes, etc and we have a great solution that everyone understands.
There - that's it - my first thought of the day - this is going to be addictive to be able to organize all of these Architecture thoughts in short bits, as I have them.
The Start of ASolution - is it Data Architecture first?
Today I'm thinking about how important data design really is to solution design. I often wonder if our roots in Information Technology will always take over our thoughts - I used to work exclusively with data and moved on to Architecture. Now, when I work in the System Architecture space, particularly on design or solution, I revert to data - and often first.
We need to understand what the data will look like and what is needed before we can design. After all - information technology is about information and always about moving it around. We manipulate, massage, analyze and display it - what impact does it have?
Today I am trying to help clients come up with a new way to allocate files based on a bunch of business parameters. Over the years, they have bandaided the process, and morphed it based on many business needs that have nothing to do with the allocation itself. It was almost mind numbing to walk through the paths and rules that had been added over the years. I'd get
frustrated and start over and over going back through the data.
Eventually I thought "this is crazy - what are we really trying to do here, and what is the bare minimum of information we need?". Simplifying things brought clarity. After I weeded out all of the special cases, I found that the solution was rather simple - there were two basic methods, with a third method that could be applied to one of the first two based on a third parameter. Voila - done. Add a bit of history logging to enable lots of great reports on performance, volumes, etc and we have a great solution that everyone understands.
There - that's it - my first thought of the day - this is going to be addictive to be able to organize all of these Architecture thoughts in short bits, as I have them.
Subscribe to:
Posts (Atom)
