I just moved my blog to www.MikeTheArchitect.com . The RSS should still be the same so if you have linked to my blog through the blogs.msdn.com/MikeWalker address you will need to update your links.
A teammate and I were chatting about search ranking and I was telling him about how I am battling it out (maybe battling out is a bit of an exaggeration) with other Mike Walker’s in the world especially the one from the National Enquirer.
I am happy to announce I have done it! After many years of being second to Mike Walker from the National Enquirer I have finally moved up to the #1 position, but for how long. I won’t last past the next movie star scandal.
Thanks everyone that have linked to me and subscribed to my blog!
http://www.google.com/search?hl=en&q=mike+walker
Results 1 - 10 of about 17,700,000
Technorati Tags:
Mike Walker
There has been some really great announcements coming from Microsoft in terms of Green IT and Sustainability here in recent months. One big one is the Environmental Sustainability Dashboard.
Watch Environmental Sustainability Dashboard Demo
Top down support is coming from Steve Ballmer as today he sent out a corporate responsibility letter to the company outlining all that we are doing in this space. He says,
"Addressing global warming is a responsibility we take very seriously at Microsoft." – Steve Ballmer
You can find the details of this on a new site on Microsoft.com called Innovating to Improve the Planet. there you will find what Microsoft is doing to be Green and help customers be Green.
There are additional activities that are happening at Microsoft to help with this problem. For one, my team. In my team, Lewis Curtis is focusing on Green IT and Virtualization. He has provided insights into this problem a bit:
The Software Enabled Earth blog is another great Green IT / Sustainability resource for news and activities from Microsoft.
Technorati Tags:
Green IT
All the time I get the questions about how to do current state architecture or “as-is” architecture at executive briefings (EBC), at events or through our customers. Recently I was asked about this in regards to an effort a large enterprise that is undergoing an effort to map out what their current architecture. As with many companies large and small, there is a reconciliation of IT assets that are being being collected and hopefully distilled into something meaningful to make decisions off of. This is compounded by the economy that has a tone of “doing more with less” and IT optimization.
With the question of current state architecture, it is both a deep and vast area to cover. As you can see from my choice of the image above (depiction of Christopher Columbus claiming the New World) this is a substantial space to cover.
The reason I say this is that it isn’t as simple as understanding a modeling language or notation and then run out and document your enterprise. Outside of the tooling, architecture standards and technology you must understand some outside forces when performing a current state analysis. Below are a sample (not in order) of aspect you must understand:
- Deep understanding of the CEO & CIO mission and objectives
- Deep understanding of mission critical solution areas
- Deep understanding of the enterprise
- Deep and vast understanding of the business
- Vast understanding of your IT landscape
- Vast understanding of your industry
You maybe wondering, I am an architect why should I care about these? Simply put, you must care because you will have to figure out where to start from. Do you start at the CRM system? How about the mission critical Online Banking System? Or maybe start simple with the FoxPro database applications in a LOB somewhere.
If you are not careful you can get a derive to a current state that is neither understandable or usable as seen from the popular example below:
Having context and purpose before walking into an very nebulous architecture effort such as this very important to your overall success. Metrics being the driver of success here. If you are able to qualify the effort you can get some measures of success out of your effort.
So to be effective at you current state analysis we must tie into the organization priorities through a repeatable framework. This corresponds with a repeatable current state process or methodology that is derived from the mission and strategies of the company all up. A model like shown below.
I often hear of horror stories of companies doing a massive current state analysis that turns into a multi-year project and yielding minimal results. The key here is to be strategic about your current state architecture efforts. The issue is that it is easy to “rat hole” into the classic problem of analysis paralysis.
This is an iterative process of focusing on assets that are the highest to lowest priority. Since the future state of any company and subsequently the IT environment is always in motion, we must be mindful of that this movement will occur and build that movement into our plans. The most effective way to deal with this is to create an iterative process like the one below to effectively perform a current state analysis.
As you can see we are bridging the CEO/IT strategies into account and letting that drive the current state analysis. Effectively we want to focus on the top priorities of the company first and then iterate the process for the next tier of priorities.This solves the problem of the is that the enterprise loosing focus on the assets they should be identifying at the right time.
An example of segmenting tiers is shown below.
Each enterprise will have a slightly different way of looking at this but the process should be similar. The tiers will also be implemented in waves. Meaning that you should perform a current state analysis in digestible chucks. I wouldn’t do more than 10 systems at any one time. This keeps a level of focus and increases the overall success of the effort. The only exception here is that as you move down the tiers you can get away with looking at more solutions at a given wave.
Obviously, when we look at implementing this model there is a great amount of detail that needs to be covered in the people, process and tools but this will give us a common way of thinking about the problem.
Without getting too much into process I will focus on where the industry is at with useful standards or tools that will help execute on a current state analysis. With that lets look at defining architectural models and how to build them.
To determine what a architectural model is or sometimes even just as important what an architecture model is not we need to start with a fundamental architecture taxonomy and ontology. Both of these terms are broad and have deep implications but if we keep it simple and say that an ontology that defines a consistent set of definitions on assets, concepts, abstraction and classifications. Then having a taxonomy will show how these pieces fit together in the context of architectural descriptions. This will help qualify the architectural models in the enterprise.
A good starter resource would be to look at IEEE 1471. I wrote a post about this (Making Sense of Architecture Standards) describing what IEEE 1471 is all about an how it contrasts with other standards. There is also a good article from the Open Group entitled Impact Assessment of IEEE 1471 on TOGAF that contrasts IEEE 1471 with their EA framework.
For more information on IEEE 1471 go to their web site at: http://www.iso-architecture.org/ieee-1471/index.html
There has also been some recent developments in this area as from the framework community. TOGAF 9 has released the start of what looks to be promising in two areas. If this continues to grow from the user community I think it could be very compelling.
- Taxonomy and Ontology / Metamodel - I reference this in my post TOGAF 9 Release and Impressions where I talk about their metamodels and repository efforts. TOGAF is making strides in this area. Granted there still needs to be more work but it looks as if they are heading in the right direction. What’s positive about this even though it isn’t complete is that there is a ground swelling of support and community that is vested in this. Unlike other architectural standards, this one has a significant community that can help drive the standards forward. The side effect of this is that it becomes the defacto standard based on the shier amount of architects in that community thus having a level of uniformity in the industry when thinking about architectural information models.
- Modeling and Notation – Now that Archimate is part of TOGAF there is now cohesion between the metamodel and the actual model with an architecture markup description language (ADML) and modeling notations.
Even though frameworks provide a lot of value be careful not to loose sight of the objectives. It is easy to do. Also, you may want to borrow from multiple frameworks as there are aspects of each that are unique in it’s own way. For example, Zachman provides a great way to group and classify information but you could use another framework like TOGAF to introduce decision making process to that, likewise with all the other frameworks.
All in all, a very exciting time for architects. There is a lot of new developments and opportunity to further the industry.
Other related posts that I have made externally on my blog that may help you out are listed below as well:
There is also a Enterprise Architecture Toolkit that was developed that aid with some aspects of this:
Share this post : 
As you can see I am playing a bit of catch up as TED has been over for awhile. Barry Schwartz makes a passionate call for "practical wisdom" as an antidote to a society gone mad with bureaucracy. He argues powerfully that rules often fail us, incentives often backfire, and practical, everyday wisdom will help rebuild our world.
Below is the video, Barry makes some very interesting points and I agree with them in an ideal world. But where this all falls apart is when you are the only ethical person in the organization. This is an all or nothing concept, unfortunately I think most corporate cultures are ready for this.
I had an interesting conversation with a friend of mine that resulted in some disagreements on root issues architects face. The topic of the Architect Nemesis came up. Where some of assertions were accurate it was still founded on a fundamental belief the we should correlate software architecture to the architecture of structures.
So what is the REAL Nemesis of Architecture?
Is it the engineer? Is it the templates and patterns? The CIO? NO…
I believe that the real nemesis of architecture here is in the name itself. Unfortunately we as an IT industry continue to compare ourselves with traditional architecture. Why is that? Well I think because it looks viable on the surface.
Here is why I think the Structural Architecture is different and why we shouldn’t compare the two (at least without having an understanding of where the analogy breaks down):
- Maturity – traditional architecture has a head start of approx. 10,000 years old starting with Neolithic architecture that was around before 8000 BC. Since architecture has been around for such a long time there are clear lessons learned. A clear collection of knowledge, true repeatability and reuse, standardization and the creation of architectural styles.
- History of Architecture – It is unfair to compare software architecture history to traditional architecture history. Contrasting with eras such as Classical –> Medieval –> Renaissance –> Modern architecture is looked at as a linear progression while it is far from a linear progression. As an example, before the fall of Rome there was running water and toilets in homes while it took close to 2,000 years to get that back. Another example is in South America where archeologists found ruminants of Nickel being created where that same feat wasn’t accomplished till the early 10th century. The history of architecture is a complex one driven by many forces and sometimes the great innovations are lost though time. The history of IT architecture is but a fraction compared to the architecture of structures.
- Motives and Intent– The great architecture that are typically referenced in software architecture are by the Romans, the Greeks and occasionally the Egyptians. The problem with this is that the drivers to build these great architectures where often not the same drivers as for software architectures. These great architectures of ancient times were built based on personal ego, religion and conquest. Examples of this include: Via Appia roads in Rome (support conquest), Pantheon in Rome (ego/religious), Taj Mahal in India (religious), and Parthenon in Athens (religious). For software architecture the primary drivers are business drivers. Not how to sustain a legacy of an emperor or have a religious structure symbolize an ideology but to solve a set of problems for a particular point in time. Solutions are put into a portfolio because we know they will change (sometime radically).
- Accountability Inherent – Building architects are accountable for there work when their specification fail while software architects are not. An example of this is the case of an architect stealing a design for the Freedom Tower or the example of MIT that sued well known architect for defective structures. There is clear accountability whereas I still haven’t heard of someone getting sued for copy & paste…
- Models are Concrete – No ambiguity in a model from a building architect. Like the quote from George Box “all models are wrong, but some are useful”. This resonates and is very true in the software industry. It is very common to see an outdated and obsolete model hanging outside a cubical that isn’t fully understood by the IT staff supporting. While you will never find an inaccurate city planner model. Two different worlds on what is acceptable from the models.
- Accreditation and Certification - Unlike the software architecture field, architects must be certified to work on an architectural project. This is vastly different in the software world. Often times the title of architect is given as a promotion to an engineer, a trendy title or just lack of understanding of what an architect really is. This leads to a level of ambiguity in the definition of what really is a software architect.
These are some initial points on the differences of these two vastly different professions. While they look relatively similar on paper they are different. Time and time again I see the correlation between these two professions and keep seeing the inaccuracies and false comparisons which I think leads to confusion and mistrust of our business leaders.
While I have been guilty of making these references when trying to convey ideas with something relatively similar. You maybe wondering if there are other parallels we can reference as software architects, I am not sure. How about the profession of an artist? Software architecture is more art than science, right? At least for now…
What are your thoughts?
Technorati Tags:
ArchitectureShare this post :
There is more big news on the Open Group front these days with the just announced a merger with the Global Enterprise Architecture Organization (GEAO) that will affect the worldwide Enterprise Architecture (EA) professional community.
The union between the Association of Open Group Enterprise Architects (AOGEA) and the GEAO forms the largest professional body for Enterprise Architects in the world, serving more than 9,000 members in 72 different countries. Please see the below press release for further details.
According to various Forrester research reports on Enterprise Architecture there is growing acknowledgment and interest in EA and its ability to assist business leaders in making critical business decisions that align an organization’s business and technology strategies. Given the growing awareness of the EA profession and the role it plays relative to IT and business, the merger between The Association of Open Group Enterprise Architects (AOGEA) and the Global Enterprise Architecture Organization (GEAO) is expected to have a great impact on global businesses and the EA professional community--bringing increased job opportunities through expanded certification programs (TOGAF and ITAC), ongoing advocacy and education services, and peer networking opportunities at local chapter meetings and international events.
Share this post :
As some of you may know I aided with the Application Architecture Guide 2.0 materials which will soon be a blue book this upcoming year. J.D. Meier who was the brains and the mass orchestrator of the guide has put together a great compile of his works over the past few years. Check it out.
Guides
Performance
Books / Guides
Methods
Guidelines
Checklists
Practices at a Glance
How Tos
Security
Guides
Methods
Threats and Countermeasures
Cheat Sheets
Guidelines
Checklists
Practices at a Glance
Questions and Answers
Explained
Application Scenarios
ASP.NET Security How Tos
WCF Security How Tos
Visual Studio Team System
Guides
Guidelines
Practices at a Glance
Questions and Answers
How Tos
Technorati Tags:
ArchitectureShare this post :
Mike Kavis posted a high level cheat sheet for the Extended Enterprise Architecture Framework (E2AF) on his blog today. Here is the description from his post:
I Basically took all of the topics from the E2AF matrix and built a document with bullets representing each topic. It is organized by the six key questions (Why, With Who, What, How, With What, and When) and has sub categories for each question by the four different view points (Business, Information, Information Systems, Technology Infrastructure). In Appendix A, I included several links to the website where the E2AF information can be found. Appendix B lists all of the E2AF deliverables.
I am really happy to see Mike Kavis is making this framework more actionable. As you could probably tell from my comments from TOGAF, I see that one of the biggest issues with these frameworks is the execution angle. In general, the template that was posted could be applied to other frameworks or even homegrown efforts as well.
My only critique would be that while the template provided by Mike definitely has all the placeholders and high level areas that are needed to be addressed it will still take some time for folks to digest all the data that needs to go in those placeholders. I would suggest putting more detail around the information that needs to be gathered in each section to help new people to E2AF or any other EA discipline understand what kind of data goes into each section. Either way it’s still a great free template to use as one of the tools in your EA Toolbox.
You can download the document here as a zipped file from his post.
Share this post :
Ran across an interesting post from Johan den Haan in which he shares his thoughts on the Top Ten Misperceptions and Challenges of Model Driven Development (MDD). This post was based on another article on InfoQ.com here: http://www.infoq.com/articles/mdd-misperceptions-challenges
Read More:
http://www.theenterprisearchitect.eu/archive/2009/01/21/10-misperceptions-and-challenges-of-model-driven-development
Two weeks ago I had the pleasure of talking with Allen Brown, president of the Open Group regarding the latest TOGAF release. Thanks to Allen and his team for taking the time to chat about the new aspects of TOGAF 9. All the details of this release will be available today on the Open Group website. Additionally, there will be a great deal of information given out at the 21st Enterprise Architecture Practitioners Conference.
I will share with all of you the highlights of the conversation. I will not be able to give a full analysis of the framework. Rather, touching on the major components, impressions, opinions, areas of improvement and concerns.
At version 9 there is quite a bit that is new. For the Open Group this is a significant milestone for TOGAF. Before we get into what’s new, lets look at current momentum behind TOGAF to date.
- TOGAF has more than 90,000 downloads. All documentation for TOGAF is published online. While this doesn’t tell us that there are 90,000 people using TOGAF, but what it does tell us is that there is significant interest in what TOGAF has to offer.
- This year there are over 8,491 certified practitioners. This is largely due to the how architects are certified in TOGAF. The Open Group has a franchise model that allows independent trainers and companies to certify architects. This is a brilliant way of certifying architects as it doesn’t force everyone going through the Open Group channel directly.
- Grew 529% since October 2006, which also includes a solid stake in 80% of the Fortune 50.
- More than 180 corporate members of The Open Group Architecture Forum
- Over 20,000 TOGAF™ series books shipped
- The online forum Association of Open Group Enterprise Architects has had a significant impact and it membership is at more than 8,500
What’s New in TOGAF 9
Below are the new features of TOGAF 9. The bolded text is what was provided by the Open Group. The regular text is my commentary on it.
- Modular structure – I am a firm believer that enterprise processes are modular pieces that should be orchestrated based on the specific set of concerns. It is good to see that TOGAF feels the same way.
- Promotes greater usability & encourages incremental adoption – This is somewhat lofty and subject largely to implementation details. I do agree that the guidance provided does promote reusability. This is reinforced with the first bullet on the modular structure.
- Supports evolutionary release management -
- Content framework – This is a significant step in the right direction. The content framework provides architects with a map of information that is needed. From what I have seen so far there isn’t a great amount of detail here. But I am sure there is more to come.
- Extended guidance on using TOGAF – The TOGAF book was expanded greatly with new guidance that extends the base concepts of TOGAF and supports new features.
- Explicit consideration of architectural styles – In the guidance there are linkages between the TOGAF ADM and Service Oriented Architecture (SOA). I am hoping that this isn’t a tight coupling. If you are interested in my thoughts on architectural styles I wrote a post on this not too long ago. See the post What is an Architecture Style?
- SOA and Security – This could be interesting. But only if done right. The Open Group needs to be careful at balancing out too much in the developer details (what OASIS & W3C provides) and high level / nebulous guidance (Analyst firms) that isn’t actionable. What could be of great value is if the Open Group embarked on true architectural patterns and styles that would aid SOA and EA architects on choosing the right architectural strategies.
- Further detail added to the Architecture Development Method (ADM)
What Architects Will Care About
My first thought after talking with Allen and his team was just how much there is to the new framework. It is obvious to that there are positive contributions from the new members within the past couple of years. Below are the ones that you will want to know about/
1. The Content Framework
One such member is Cap Gemini. Cap Gemini donated most of the Architecture Content Framework. In my opinion, this was long overdue.
Content framework provides:
- Linkages and the information that is needed in the Architecture Development Method (ADM)
- Defines the work products that are needed
- Classifies information and shows high level relations. In the documentation it states there is a metamodel but I did not see one. There are high level entities defined but didn’t robust metamodel definition.
- More information is provided in the Architectural Principles, Requirements and Vision areas
2. Better ADM Guidance
The augmented crop circle diagram is a great example of new guidance that will aid architects in implementing TOGAF.
Other ways guidance is extended are:
- Applying iteration to the ADM
- Applying the ADM at different enterprise levels
- Security architecture and the ADM
- Using TOGAF to define and govern SOA
3. Restructured Modular Approach
The image above shows how the pieces of the existing standard have been restructured and have additional aspects. With the restructure existing pieces where used to ensure backward compatibility with TOGAF 8.1.1. Specifically it preserves:
- The core Architecture Development Method
- Existing investment in people - knowledge and skills
- Existing investment in tools
4. Architecture Modeling Notations and Architecture Markup
While I didn’t find mention of Archimate and ADML in the pre-release TOGAF 9 documentation I did however have a conversation with the Open Group folks about Archimate. It turns out that ADML and Archimate is converging and will be part of TOGAF 9. I would share more details but I just don’t have them. I do think that this important to keep an eye on.
If you are interested in my previous conversations regarding Archimate and TOGAF 9 you can find the post “ArchiMate - The Emerging Architecture Modeling Standard?” I wrote a few months back.
5. Playing Well With Others
It’s good to see that collaboration with other standards bodies and commentary frameworks is still encouraged. This is critical for the long term success of any Enterprise Architecture Framework.
6. Community Driven
TOGAF 9 was developed, reviewed and approved by a collaborative of 300 members from some of the world’s leading IT customers and vendors. One example of the contributions is Capgemini:
Mike Turner, TOGAF Development Lead at Capgemini explained: “We consider an architecture-based approach to be essential for enterprises to manage change across business and IT, even more in a period of downturn in which tangible business outcomes come first. The open standard nature of TOGAF allows our clients to truly collaborate with their partners in the definition and management of change by using shared concepts, content, processes and tools. TOGAF 9 is a huge step forward, particularly because it standardizes and materializes the content that architects work with. We were most happy to contribute to it, leveraging much of Capgemini’s established and widely respected architecture assets.”
Areas that Need Work
With the good comes the bad and in this case there wasn’t anything bad, just areas that I will be looking forward to see more progress on. Below are those areas of opportunity for TOGAF v-next.
1. Processes are Abstract
Many of the areas still seem to be very high level. While this is what I like about TOGAF, it is also a liability. I have seen the same issues in other standards bodies where the standard is so abstract it isn’t useful. I don’t think that is the cases here but what I do know is that it is subject to interpretation which can result in poor execution of the framework.
2. Metadata Repository
There still is a great deal of definition that needs to be done here. The first level of detail is good, there are linkages to the ADM and Content Framework but there is little in the area of real world implementation. I couldn’t find any schemas that would help companies build a repository in compliance with TOGAF.
The Open Group might be relying on vendors to define this for the industry. That can be problematic however.
3. Making the Framework Actionable
Getting started with any new framework is difficult. I was hoping with this latest release that there would be accelerators that would aid architects adopt the TOGAF framework. As I mentioned many times, TOGAF is a process framework that is abstract from a lot of the implementation details but I think it is time for the framework to become more grounded and more importantly provide immediate value through accelerators like:
- Templates
- Checklists
- Samples
4. Metamodels too High Level
TOGAF 9 does a great job at exploring the architecture metamodel at a high level. There needs to be a level or two deeper of consideration here. I was looking for more detail on:
- interaction between the architectural domains
- composition of the domains themselves
- non-functional requirements called out specifically
- organizational aspects spelled out such as geography, LOB, business unit/division, etc.
5. Limited Taxonomy and Ontology Defined
The framework has elements of a taxonomy and even borrows from some like IEEE 1471 but doesn’t have an all encompassing taxonomy to describe the structure nor an ontology to define information in that structure.
This isn’t a deal breaker for the framework. There are multiple areas where there are less formalized (from a taxonomy / ontology perspective) definitions throughout the documentation.
Conclusion
Whether you are using TOGAF in your organization or not TOGAF 9 is definitely a framework you want to evaluate. I didn’t find anything that was negative about TOGAF 9. Even though there are some gaps and some areas that could be more developed the bits that are refined were really good. Keep in mind that the focus for TOGAF is still mostly at the process level and dealing at a high level of abstraction should be expected.
Share this post :
The Canadian IT Architecture Connection blog posted about a one day EA course that may be interesting to folks in that area. See below for details:
Phil Unger, from the Calgary Enterprise Architecture Forum, is organizing a one-day course focused on developing the skills Architects require in their day to day work. The course will run March 4th, 2009 in Calgary. If you are interested, please contact Phil or Craig for the abstract and registration details.
This course provides students with a theoretical and practical understanding of the subject
areas related to enterprise architecture plus technical and business opportunities and
industry trends.
The course, delivered by Jamshid A. Vayghan Ph. D, will cover topics in Enterprise Architecture, Enterprise Architecture frameworks, Enterprise Service Oriented Architecture and the unique aspects of enterprise architecture and development.
Taken directly from the abstract, the following are the key benefits to Architects:
- What is enterprise architecture and its importance in the current business
environment? We will discuss barriers, opportunities, risks for implementation of
an enterprise architecture program and ways to overcome them. We will also
discuss how to identify the scope of an enterprise architecture to make sure it
aligns with business strategy plus ways to identify business values from an
enterprise architecture program. - How to recognize the need for enterprise architecture in an exiting organization
and ways to create a proposal for an enterprise architecture initiative. - You will learn an implementation methodology that you can use to initiate an
enterprise architecture program. - You will learn Service Oriented Architecture and how to use it to design and
implement enterprise applications. - You will learn three enterprise architecture frameworks and how and when to use
them: Zachman Enterprise Architecture Framework, The Open Group
Architecture Framework (TOGAF), Enterprise Architecture Cube methodology - You will learn why governance and standards are as important to development of
enterprise application and architecture as technical architecture is. - You will hear from an industry professional with practical experience in initiating
and developing an enterprise architecture program. - How to extend what you learned in the software engineering, software
architecture, and project management courses to the enterprise application
development and architecture domains.
Share this post :
A interesting post from Michael Bullock talks about Google’s new patient approach to put data centers on ships. This was also covered in Time as one of the best inventions of 2008.
Like Michael, I think that this is somewhat problematic. We will have to see if this actually becomes a reality.
Briefly, I see the three primary concerns:
- Physical Security – While we are not in a Disney movie, modern day Pirates are real. This maybe a lucrative proposition for criminals to steal data.
- Environment – Storms and turbulent waters can cause significant issues I wonder how these will be addressed.
- Latency – I have worked and spoken with companies that have a shipping component to their IT. Most all of them talk about challenges with network latency. This could be a deal breaker for Google.
Besides giving us insight into Google’s ambitious plans to go to sea, Michael provides a great started list of considerations that you should take into account when looking at datacenters in general:
- Power Density – What type of systems do you expect to house in the new facility? If you’re expecting to support high density systems (like blade servers requiring 10kW per rack or more), how much room will you need? And if you’re planning to move into an area that only supports 150 W/SF, you will need to space out your racks accordingly (for proper airflow), increasing the amount of raised floor space you thought you needed by a factor of 4.
Power Availability – Is there sufficient power available in the grid to supply the site? If not, be prepared to foot the bill for power company infrastructure upgrades which may take 18-24 months to complete. - Power Redundancy – Is the space serviced by a redundant substation with independent power feeds to your location (or maybe even multiple substations)? You want that unless you’re prepared to deal with downtime.
- Power Backup – If you’re looking at an existing facility, you have to ask if it has backup power to cover the center’s full load. It’s also wise to find out if there’s a clear plan in place to increase capacity as you grow. If you’re looking at a new facility, you have to find out if there’s sufficient space for backup power generators and their fuel storage tanks. And are there any zoning issues which may cause delays or add to your costs when you try to install these backup systems?
- Cooling – Is there sufficient cooling capacity to maintain a proper operating temperature in the facility even when it’s operating on backup power? Is there sufficient floor to ceiling clearance to allow for adequate cool air supply and the removal of hot air exhaust? Quick test: If you’re moving into a facility with 200 W / SQ ft. capacity, are there at least 36-inches of raised floor space to assure adequate airflow for system cooling? If you’re planning on 400 W/SQ FT? Look for a floor raised 4 feet or more. Lack of sufficient height is one of several reasons why conventional office space is suboptimal for anything more than 100W / SQ ft.
- Network Access – Ideally there should be multiple WAN providers capable of serving your facility, each with redundant fiber / network connections. This will assure long term competition on price and an alternative if one provider’s price or service levels become an issue.
- Geographic Considerations – Are you planning on putting your data center someplace where earthquakes, hurricanes, tsunamis or floods occur from time to time? I wouldn’t. Will planes flyover it making their approach to a nearby airport? I’d think about that. Will it be easy to deliver replacement parts and get professionals there for needed repairs or maintenance? Is the location safe from terrorism or desperate profiteers like Somali pirates?
Technorati Tags:
Data Center
