We’ve seen it many times. As a company grows, intelligent people within the company want to manage their data in ways that will help them do their jobs. What could be wrong with that? Not a thing. People can do some pretty amazing things with spreadsheets and database applications. As companies grow – especially from small to mid-size – the tendency for departments and individuals to create these data islands increases.
There’s one problem. These islands of data are just that: islands. Data is only as useful as it is accessible by the right people at the right time. Sometimes data can get stranded and inaccessible. Smart CEOs and managers take steps to ensure that both the input of data and output of data continue to be available.
Granted, there are definite advantages to independent data marts running within an organization.
- They help bypass corporate bureaucracy and red tape.
- They empower individuals to manage their workload, sometimes in very creative ways.
- And they allow for changes to applications and macros can be made on the fly.
Unfortunately, the list of potential disadvantages is lengthier:
- Uncontrolled data access. If you put the application on the network without security, anybody can see everything. On the other hand, perhaps your company’s decision makers make poor choices, not knowing the data is already available.
- Poor communication between the data island and corporate data warehouse.
- Data and application failure danger, especially if running on a standalone computer.
- Limited awareness of what all is happening with data within the organization. What happens when Joe Wizard takes an extended vacation, or leaves the company altogether? What if his data is password protected? What if an employee or manager spends hours re-creating a report that already exists in a different system?
- Poor documentation. Sometimes it’s difficult to know how to run an application, and the impact that changes to data will have in other areas.
- Departmental turf wars that arise as work groups challenge the accuracy of each other’s data or the effectiveness of their applications.
- Redundant Data. As the number of islands grows, the amount of redundant data can grow uncontrollably across your company. And no wonder. Each island requires its own, typically duplicated, copy of the detailed corporate data.
What’s the solution?
At a minimum, explain your corporate policy, outlining the need for software applications to be documented and shared with management. This may even fall into the realm of Sarbanes-Oxley requirements for your company.
Rather than fight with the geniuses who built individual applications, embrace their creativity! Ask for their input on how to incorporate updates into your corporate database. Designing effective applications from scratch can be a daunting task. Why not use what has already been created as the starting point for discussion?
Data consolidation doesn’t have to be expensive, or impede the ability of people to be more productive. If done right, it will actually help everyone across the company see the data they need, when and where they need it.
In order for us, or anyone else to provide you with an accurate proposal, your company would benefit greatly by having a detailed design specification drawn up, then using it as your road map for the actual software development work. It can serve as a great reference point and benchmark.
What is a design specification?
A design specification is a document which describes what a completed application will look like. It spells out the required characteristics to be considered for awarding a programming contract-including sufficient detail to show how the application is to be created.
A completed software design specification should do all of the following:
- It should be able to adequately serve as overview for programmers, giving them enough information and understanding about a project so they can get up to speed quickly, and won’t feel overwhelmed when asked to create or modify source code.
- It should serve as the blueprint that designers and programmers use to benchmark whether they’re designing the application in keeping with the original intentions of the design team.
- It needs to be as detailed as possible, but must not impose such a burden on the programmers and implementers that it becomes overly difficult to create or maintain.
- Finally, it needs to explain what will not be included in the finished product. This will help ensure that all project stakeholders are on the same page.
Using a design specification will ensure that:
- Your company’s expectations are documented, and agreed to by all decision-makers within the organization
- All major design issues are unearthed and addressed
- Your time and effort isn’t wasted by repeatedly explaining project requirements to multiple developers
- Priorities and timelines for all the desired features and components can be established
- Objective cost/benefit analysis can be performed
- The resulting proposal(s) can be compared against a single standard. It’ll protect you from having to compare quotes on an apples-to-oranges basis.
- Your company’s expectations will be met by the developer who ultimately develops your new system
The procedure we follow when writing a system design specification includes these steps:
- Preliminary investigation – thorough review of all documentation and other materials provided by client
- Conduct interviews of key personnel as identified by management.
- Define project scope and constraints
- Create comprehensive system specification document
- Present results and recommendations to management
- Adjust specification per management feedback
- Deliver final specification document to management
The Next Step
After these steps are performed, you now have a tool you can use to solicit detailed proposals from as many developers as you like.
OK. It took some tinkering, but I figured out how to configure network settings inside CentOS-6, to complete the migration. I had to change the settings to use a static IP address and specify the right gateway. Then I started looking into different themes. For now, I settled on WordPress’ TwentyTen theme, but tweaked the logic under the hood, adding some custom PHP to incorporate Google Adsense. It wasn’t too difficult–just took a little trial and error. So now there’s a banner ad at the top, and a skyscraper on the right.
Somewhere, someone said that you have to download a plugin to accomodate Adsense. Maybe that was old information, or maybe it’s still true if you don’t want to hack the underlying php code.
This concludes the initial development and setup of blog.iotechno.com.
Yes, CentOS appears to behave better than Slackware did–at least as far as WordPress is concerned. I was actually able to install a plugin on the new machine. However, I wasn’t real impressed with the WordPress Import plugin–it didn’t appear to do much at all–even after I got it installed. What really made the difference was doing a mysqldump of the wordpress database on the old server, and importing it into this one. Then all the posts showed up like nobody’s business.
All that’s left to be done is to change this server’s internal IP address so that it routes correctly out to the internet. Then I can start looking into installing a different theme and additional plugins.
After our new Qmail server was up and running and all the major issues were ironed out, it was time to clone the email server’s hard drive to a backup drive we can store off site. I decided to do this at around midnight, so that our day-to-day business wouldn’t be disrupted. The biggest challenge was actually finding a workstation that was big enough to house two drives and had enough available SATA power plugs. (I realize, you can also push compacted images up to an FTP server, but I was afraid our FTP server wouldn’t have enough space to accomodate the complete disk image.)
My biggest fear was that I would clone images in the wrong direction. In other words, copy the garbage image from my intended target drive over the top of my intended source drive. But the G4L menu now has an option that allows you to identify which disk is which. So with a fairly high level of confidence, I cloned disk1 (/dev/sda) over the top of disk2 (/dev/sdb). Not sure how long it took–I went home after verifying that the process was running.
So this morning, it was just a matter of quickly inserting the original disk back into our email server and firing it up. Then I tested the cloned image on a separate (but similar) machine. Woo hoo! It works!
I struggled to install a couple of plugins and received the message: An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums.
Yeah, right. Try again. Try finding an explanation as to what’s causing this or how to deal with it, but no joy. Oh, I found a thread that amounted to an argument between other frustrated WP users as to whether they should start a separate thread about this issue or not–but no solutions appeared on the horizon.
So here’s what I’m going to do: Abandon this Slackware install. I googled the question, “Which is the best distro for WordPress.” The concensus seems to be either Ubuntu or CentOS, with more answers leaning toward CentOS. I’m not a big fan of Ubuntu–seems too much geared for users who don’t need or want to get under the hood. And I’d prefer not having to use sudo all the time.
So for now, I’m downloading CentOS 6.3 and will install it on a different machine.
So far I’ve been able to get WordPress running–up to a point. As long as the updates that I want to submit are saved into the MySQL database, everythings fine. But when I tried to upload a different image to customize this blog site, it started getting ugly. The site returned the message: The uploaded file could not be moved to /wp-content/uploads/2012/08.
I searched for solutions online. One suggested tweaking the upload folder, adding/removing leading / trailing forward slashes. That didn’t work. Others suggested that you have to update permissions to 777. I was hesitant to do so, because that’s just throwing the door wide open for hackers. But after messing around for several hours, I decided to give it a try–thinking that I’d be able to reset permissions afterward. For me, that fixed the issue. Our blog now displays a custom header at the top of the 2011 theme.
I also tried adding a comment to see whether I could. Since this wrote straight to mySQL, it wasn’t a problem. But I noticed that the site didn’t email me a notification–even though it appears to be configured correctly. I suspect the issue is that I didn’t install sendmail on the machine. I’m going to poke around some more to see whether I can use smtp passthrough to route emails back and forth between this new machine and our mail server. I’ll update this blog once I figure that out.
When I first set up this blog site, I hadn’t configured DNS yet, so it was easier at the time (or so I thought), to just use the intended IP address. Little did I realize that this particular IP address was being saved into the underlying MySQL tables! Only later, when the blog server received its final static IP address assignment and I updated DNS accordingly, did I realize how much of a challenge this would prove to be.
Googling for ‘WordPress IP Address change’ resulted in a number of links confirming that yes, this was not going to be a cake walk. The accepted solution on stackoverflow was this:
update wp_options set option_value=’http://www.yourblogname.com’ where option_id = 1;
update wp_options set option_value=’http://www.yourblogname.com’ where option_id = 39;
While that helped, it didn’t totally resolve the issue. Ultimately I ended up doing a mysqldump of the database, opening it up in Notepad++ and substituting blog.iotechno.com for the original IP address. After saving the file to a different name (just in case importing the .sql script might screw up the database structure), I launched mysql and imported the new script. Worked like a charm!
After a fairly steep learning curve, I finally have WordPress up and running on a Slackware 12.37 box. It was actually easier the second time around, after I spent several days trying to install Qmail, then configuring and deploying it on a new machine (also running Slackware 12.37).
I’m sure there would have been an easier way than the one I took–deploying a barebones install of Slackware (deliberately NOT installing Apache, MySql or PHP during the setup), then manually installing the components. But for the life of me, I couldn’t get the three from the base install to peacefully coexist.
But hey, it’s working now!