10 Steps to Develop an IT Strategy


I have been looking for a good guide in the Internet for steps in developing an IT strategy.  I found many of them out there, but they either miss the important, or elaborate on one step in the expense of others.  So, I have decided to pull together a comprehensive list of important steps someone needs to walkthrough in order to develop an IT strategy.  So, here they come:

1. Develop Charter – to get initial agreement on planning

A charter is a great tool of debate and agreement.  Before you spend a great deal of time in developing an IT strategy, it is worth agreeing on and justifying the effort.  Also, a charter serves as a proposal of an project you’re planning to conduct, and will be a great tool to sell the idea to the CIO, and the overall organization.

A typical IT Strategy Charter answers the following:

  • Objectives: why are you pursuing this exercise? and what kind of background work has already been conducted that could possibly contribute to it?
  • Critical Success Factors: what are the rules of engagement? what are the make-it-or-break-it conditions for a successful development of your IT strategy?
  • Scope: to clarify and limit activities and coverage of the IT strategy.  You could scope the deliverables, scope the process, or scope according to available data and capabilities.
  • Governance: how do you plan to run your planning process, and what people and team structure you need to establish? what is the rhythm of collaboration that facilitate the planning exercise?
  • Methodology: are you going to refer to a framework to guide your activity? and which process (relevant to strategic planning) are you proposing to follow to reach your goal (apparently the 10 steps in this post!)?
  • Deliverables: describe the expected deliverables and link to methodology/process above.
  • Timeline: of your strategy development process reflecting dependencies and durations.
  • Budget: what funding and resources do you require in order to conduct the planning exercise?

Remember, your charter is a selling tool, so make it concise and value-emitting.

2. Capture the Business Context – vision, mission, values, and strategic goals

A critical success factor of your IT strategy is to mirror and align with the business.  In this step, you need to capture (or create) a crisp understanding of the business that IT serves.  You usually do that be reviewing the business strategy, which typically contains the following elements:

  • Vision of the organization
  • Mission/Purpose
  • Values that govern the souls and activities of its people
  • Strategic Goals: usually arranged in focus areas or themes.
  • Strategic Initiatives: detailed programs and projects that the business is planning to execute in order to achieve its vision, mission, and goals.

These elements will enable you to build IT’s version of vision/mission, and understand the implications of business strategy on IT (via analyzing the strategic goals and initiatives).

3. Develop IT Mandate: Vision, Mission, and Objectives

Although might not be required, but we as IT people love to tailor everything to our likings.  In this step, you can technologize the organization’s vision and mission, and state your high level goals or objectives.  I love to call this IT mandate, as it really all about what we aim for, what purpose we serve, and what governs our activities.

Someone could expand this step to state all possible guiding principles that govern our choices; An area where Enterprise Architecture is very concerned about.

4. Define Critical Success Factors – or rules of engagement

The play the game, you need to state the rules.  A critical list of success factors will help depict high level requirements that you want to ask top management to secure.  Leave the details to be explored in future steps such as governance and implementation roadmap.  You would usually have 3-5 CSF’s to set the stage for a successful planning exercise.

5. Analyze Current IT Environment

That’s where the heavy-weight lifting occurs.  An analysis of your current environment (current state, or status quo) is required where you do lot’s of reflections and backward looking.  You need to pick the right tools to help you with analysis, such as value chain mapping of processes to systems and services, SWOT analysis, etc.  You will need to combine this analysis phase with input that you can acquire via:

  • Interviews with business and IT
  • Reviewing exiting documents (processes, policies, standards, organization structures, budgets, …)
  • Conducting workshops to structure the analysis and uncover the hidden.

If you need details on this step, then reviewing Enterprise Architecture will be a great source of guidance and tools.

6. Identify Strategic Issues and Outcomes

After scanning and analyzing the current environment, you will come up with a laundry list of strategic issues and outcomes.  These need to be discussed and refined via internal debate within IT, and with the stakeholders as well.  Workshop setups are the best to refine and agree on strategic issues.  This step is critical to feed the benchmarking exercise coming next.

7. Benchmark and Study Best Practices – by comparing to local and global bodies and technology trends

Benchmarking is a great tool to compare your organization with other entities and to share strategic issues seeking what and how others do about them.  It is a practical learning opportunity for your leadership team and staff.

A number of sources and/or techniques can be used when planning to conduct benchmarking:

  • Contacting other organizations that match yours in a number of criteria such as purpose, industry, and size.
  • Attending conferences and seminars that take holistic view of IT; avoid those that cover specific technologies and/or vendors unless it relates to one of your strategic issues.
  • Reviewing off-the-shelf benchmarking studies and research available from a variety of sources (such as business monitor, data monitor, IDC, Gartner, Forrester, … or world organizations)
  • Digging for reports from local government entities (ministries, commissions, …).
  • Studying technology trends from well-known vendors; but be cautious of the marketing nature of such sources.

Benchmarking serves as a reality check on what things are possible and what things that can be taken into consideration when envisioning your future state, next.  It’s also important you consider the local organizations in your benchmarking since each market have a different set of drivers and challenges, and your local market gets you practical answers and advise.

8. Envision Target State and Assess Gaps

Your IT mandate, the analysis of current environment, and benchmarking results should set you on a path to state your strategic goals and conceptualize your future state (target state, target model, vision of success…; name it the way you like).  Again, following a practice like Enterprise Architecture comes in handy with its structured approach and tools to depict a potential future state.

The future state can include one or more of the following:

  • Strategic goals – possibly arranged into strategic themes or focus areas.
  • Architecture models – conceptually depicting the future state in different areas such business, information, technology, …
  • Specific technologies/solutions recommended for adoption to address specific strategic issues (aligned with business goals).

Once you understand your current environment and envision your desired target model, you will be able to conduct a gap analysis to identify what can be done to progress you towards your vision.  This analysis will be translated into actionable strategic initiatives – programs or projects that compose your motion vehicle.  This will be captured in Step 10 – Developing Implementation Roadmap.

9. Develop Governance – to facilitate and enforce strategy execution

This is different (but could be an evolved version of) the previous governance mentioned in Step 1 – Develop Charter.  Studying and establishing an appropriate and strong governance structure will ensure that the plan will be executed, communicated, monitored, and reviewed once commenced in action.  Governance typically consists of the following:

  • Appointing one person who will be the owner and in charge of the plan.  Usually a senior who reports directly to the CIO (in small and mid-sized organizations) or Corporate and/or IT Planning directorates (especially in large organizations with well-established planning functions).
  • Identifying people who will take care of the strategy plan; the core team.
  • Identifying those who will participate and facilitate its execution within IT and Business; the virtual team.
  • Appointing one or more seniors from executive circle to steer and monitor; the executive steering committee.
  • Determining the rhythm of collaboration amongst them all via meetings, committees, workshops, reviews, …
  • Defining controls via standards, policies, and processes (such as change management).

By appropriate and strong governance I mean: physically tangible, empowered by top management with clear authorities, and culturally-fit (having a governance in public sector differs from the private sector).

10. Develop Implementation Roadmap – initiatives with priorities, estimates, ownership and schedules

Finally, we can have some real and tangible stuff that concludes this effort.  An implementation plan will basically consist of a proliferation of strategic initiatives that link to your strategic goals and/or themes.  Strategic initiatives are the result of analyzing the gap between your current and target states.  They will need to be organized to reflect the following:

  • Dependencies and priorities: which initiative to start with, and how critical an initiative is to achieve a goal or theme.
  • Budget estimates: including people, tools, and efforts.
  • Assigned ownership to ensure accountability.
  • Schedules of initiative durations, and when value can be realized.

A roadmap will result to show how we’re going to achieve what we have stated in our mandate, strategic goals, and target model.  Each initiative typically corresponds to a project, which means that they form the contact and transition point between your strategy management and program management.  Program management (typically represented by a Program Management Office or PMO) will detail each initiative into project plans.

We’re Not Done Yet!

In order for any strategy to survive, three more steps are needed that compose a tail and a rhythm of continuous activity.  These are communication, monitoring, and review.  Below is a summary of these recurring activities:

A. Communicate the Plan – consistently

Communication is one of the responsibilities of an IT Strategy Governance.  The governance structure will need to communicate both the planning (while developing the IT Strategy) and the plan (The final deliverables and the execution rhythm).  IT organization need to best utilize this step to consistently show their value, and to achieve a common language with the business.

B. Monitor Performance – regularly

Your goals and initiatives will sure have metrics to reflect on progress towards goals.  This step will be another tool used by the governance structure to monitor performance against targets.  It will usually be depicted using dashboards and key performance indicators.

C. Review Strategy – regularly and incrementally

On a predefined schedule, the whole strategy needs to be reviewed, say every quarter, half, or annually.  The governance structure need to utilize this review for course correction.  There is also another important benefit of this review cycles: incremental development of the strategy.  When you start your effort to develop your plan, you might be very limited in resources (people, budgets, timeframe).  A strategy review will enable you to augment and refine your strategy incrementally, in order to manage scope and complexity.

Scoping an Enterprise Architecture Practice


As a first step in your efforts to develop an Enterprise Architecture, you could think of chartering the EA exercise to answer important questions, such as:

  • Why would you need EA? objectives/goals?
  • What is the vision of your EA practice?
  • What would be your scope in your first iteration (typically, you cannot have EA in one shot!)?
  • What kind of deliverables are expected as outcomes of your EA practice?
  • What kind of governance you’re proposing in order to facilitate execution?

In this post, I will try to answer what goes into a typical scope of an Enterprise Architecture practice.  But first, what’s scoping anyways?!

In its simplest forms, scoping is knowing what to do, and more importantly what not to do. 

In order for you to know what (not) to do, you need to know three (3) important things of any effort or practice:

  • The final outcome desired – result.
  • The steps or activities needed to achieve that outcome – process.
  • The available inputs to those steps that enable them to richly and adequately achieve the desired outcome – input.

By scoping, you might fully consider the whole outcome (the result).  You also might think of chopping that up into smaller outcomes and tackle those one by one to help you achieve the whole result, gradually.  Note that these smaller pieces need to be logical and each need to get you closer to your grand one.

Chopping (scoping!) can affect the steps or activities to be carried our (the process itself).  That can be accomplished by either eliminating or focusing on some of the steps. Also, an important guide to chopping is the available inputs – both hard inputs such as documents and processes, and soft inputs such as people and time.

Let me give a simple example before we dive into how to scope EA itself. 

Example: Developing a new learning website.

This is originally adapted from a great book by Dan Roam – The Back of the Napkin: Solving Problems and Selling Ideas with Pictures.  As Dan states, in order to develop a new educational website, all you need is the following:

developing a learning website

Everything we need to know to create a learning/educational website
(adapted from “The Back of the Napkin” book)

This constitutes your desired outcome: a website that delivers content to be consumed in a variety of ways which would result into a brand that people will admire.  In order for you to have a manageable and effective scope, you’ll need to chop it up according to the above circles individually while maintaining the overall framework and connections. 

For instance, you may focus on digital text content, and exclude multimedia or vice versa.  You can think of delivering focused content for KG vs. K12.  For the brand, you would need to take it as a whole (no chopping), cause you cannot plan for a partial brand!.  Function can tackle delivering courseware, exams, on-site vs. off-site, self-service vs. sponsorship, etc.

On the other hand, you can see how your process (steps and activities to achieve your above outcome) will be minimized accordingly.  You would take different approaches when delivering different kinds of content (text, media, games, art, …).  You will also have focused activities on the method of delivery and consumption.

If you stop at this stage, then you’re risking the whole thing!  You didn’t consider what available inputs (or resources) you have that will enable you to practically scope that project.  For instance, delivering media content without the right people in your team who are specialized in media production/editing can be dangerous.  Including your entire portfolio of content and consumption will be different if you have a 3-month or a 1-year project, and so on.

What to scope in EA?

Similarly, we need to consider the three important things in developing an EA in order to know what to scope: the result, the process, and the available inputs.

Result – desired outcome of an EA practice:

  • What does an EA look like in its final form? – the hard/concrete part.
  • What is EA set to do or achieve? – the soft part.
  • What are the typical components and/or deliverables of EA?
  • What are the levels of detail for these components/deliverables?

Process – the steps and activities that need to be conducted:

  • Which approach or framework your planning to follow in developing your EA?
  • Which standard process (in the chosen framework or approach for instance) exist to help in knowing the step-by-step process?

Inputs – available data and resources:

  • What kind of data are available at the moment that are crucial to developing your EA?
  • What timeframe, people, and budgets you’re planning to shoot for, or already have in hand?
  • What budget are you possibly allocating for this practice?

To summarize, I’m including here an adaptation of the “Structure of the TOGAF Document” which gives a simplified view of what an EA looks like:

EA TOGAF simplified

TOGAF – simplified

One could scope an EA by chopping off its final form into pieces.  For instance:

  • By focusing on building the capability (the team), and founding the process.
  • By focusing on specific content and deliverables such as business architecture vs. technology architectures.
  • By serving specific units of business vs. the whole enterprise.
  • By affecting critical business operations leaving the rest for later.

You could also guide your scoping effort by looking at the available inputs:

  • Having a documented base of business processes gives you a head start at developing the overall business architecture.  When that’s not available, then you need to consider the effort needed to do at least a high level business architecture for you to have a meaningful scope, and hence a meaningful EA.
  • Having a timeframe of 6 months is tight compared to a 1- or 2-year horizon.  Hence, you will need to chop off your desired outcomes with time in mind.
  • The presence of senior business analysts, architects, and overall knowledge of EA within the leadership team will be a push or a pull to your efforts.  Considering this will enable you to put the required resources and plans of readiness in your scope.

Scoping according to the process steps is also possible.  The risk lies in the potential of not showing enough value in the early stages while waiting for future ones to cover and build momentum.

Objective-driven scoping:

Your objectives and goals out of developing and having an EA practice should be your guide when scoping.  If the main goal of EA is to formalize the relationship with the business and to better align with them then it wouldn’t be wise to excessively document the current and future states of the technology architecture.  Instead, you need to focus on developing the EA Governance (team, committees, rhythm of collaboration, …).

On the other hand, if your approach is technological where you need to better understand current environment to rationalize your application portfolio (by eliminating redundancy, for instance).  This will trigger a need for a scope that focuses on data and application architecture guided by a high level understanding of business vision and processes (business architecture).

This explains why breadth (which architecture domains to cover) and depth (to what degree of details you need your models to capture) of architecture is a critical element and view of your scoping exercise. 

See my post on why would you pursue an enterprise architecture for a bit of details on different approaches in developing an EA.

To Recap

You have the following views to look through when scoping your Enterprise Architecture (EA):

  • Outcome view:
    • Scope of the enterprise (business units, partners, …)
    • Scope of the architecture domains (business, information, technology, …)
    • Depth of details (considering the variety of models)
  • Process view:
    • What does your proposed process of developing an EA look like?
    • How many steps (and which ones) of that process can you plan to conduct for the present vs. the future?
  • Inputs view (works as both constraints and enrichment of your scope)
    • Available time
    • Available team and knowledge
    • Available details (documents, data, previous efforts, …)

Hope you enjoyed it, and please remember me with a piece of comment!

Further reading

For some extra reading, have a look at the following:

Why would you pursue an Enterprise Architecture?


It would sometimes disappoint the reader to look at “why” before “what”, but that is the natural way.  When you compare questions like – “Why use a cell phone?” compared to “What is a cell phone?”, you clearly can spot how the “why” question was asked first, and then attempts to define its outcome started to explode (the “what” part).  Also, the “why” part might have been provoked with other forms such as “I need to communicate on the go, how can I do that?” which is basically an answer to “Why use a cell phone?”!

So, please excuse me for not addressing other important aspects of Enterprise Architecture in this post, like “What is EA, anyways?” which I will do in the near future.  As a first post on my journey on discovering and deciphering Enterprise Architecture, or EA for short, I needed to start with a more provocative mindset.  “Why?” is always a great start!

In my reading through EA literature, I can see two distinct personas for those who pursue an EA effort.  One that looks at it as a core IT function or program to reorganize the house; I would like to call them “EA Technologists”.  The other persona looks at it as a tool to better understand and govern business interactions and deliver value; which I will call “EA Businessmen”.  There is no harm in either, but it then becomes a question of how much value I can gain from an extensive effort in developing an EA.  For example, an EA technologist will always admire the “architecture” side of EA, and will devote most of his or her time in perfecting its outcomes such as frameworks , models, repositories, standards, etc.  He will always value those architecture blueprints that help him address integration issues, business processes, and sourcing strategies, for instance.  On the other hand, an EA businessman will mostly appreciate that tangible benefits of getting closer to business and having a defined way in channeling their needs and reflecting on business satisfaction of IT.  You clearly see him or her worried, and concerned mostly with the “enterprise” side of EA. 

You could see clearly how the second persona (EA businessmen) will have a much greater value in putting together an EA, since IT merely exists to enable and advance (or even lead) business to achieve its desired outcomes.  But, you should perceive both as fine approaches to EA, with different concerns and value propositions.  It’s simply the difference between being “technology practical” and “business practical”.  Both are practical, but have different views on EA, so vote for your favorite side.

Why would an EA technologist pursue an EA effort?

Coming from the technology side, and mostly being concerned with the architectural outcomes, an EA technologist would think of developing an Enterprise Architecture to address one or more of the following (this is not a comprehensive list by any means):

  • Understanding the current environment in order to organize the house.
  • Developing standards in order to have clarity on selection of systems/technologies.
  • Drawing a roadmap of technological improvements to reach a satisfactory level of design.
  • Clarifying and/or developing integration standards to easily hook up internal and external IT systems.
  • Governing the relationship with external vendors and having a blueprint of standards which they can follow.

You can see how EA technologists, in some cases, try to address specific technology problems.  I believe this is where EA gets intermingled with other technology disciplines such as business process management, integration strategies, sourcing strategies and vendor management, etc.

Why would an EA businessman pursue an EA effort?

Coming from the business angle, EA businessmen are usually concerned with value outcomes from IT to the enterprise, which should connect to those of the enterprise as a whole!.  One or more of the following will be on the agenda of an EA Businessman:

  • Making business-conscious decisions in IT, and facilitating/guiding those of the business as well.
  • Connecting business strategy to IT strategy, or facilitating the execution of strategy within IT.
  • Clarifying IT value to the organization in order to avoid marginalizing its efforts.
  • Clarifying business needs in order to govern changes and achieve satisfaction.
  • Establishing a rhythm of collaboration between the business and IT.

EA businessmen are always business value-driven which helps them avoid unnecessary architecture jargon (no offense to EA technologists who should, in my opinion, make sure to justify every single model or artifact they produce in their enterprise architecture).  The down side of their efforts is that it is tougher to pursue and usually needs a twist in the mindset.  It is also much harder to make their efforts as concrete as those of the technologists.

Which side I support?

You might guessed my side from the above, but I wish it’s as simple as voting for one side over the other. In my opinion, you should start being an EA businessman who collaborates with or even lead business to deliver value out of IT.  At the same time, you need to dive like an EA technologist on as-needed basis in areas where you need to have concrete deliverables and tools.  This way, you can balance your act by wearing two hats (or working with a team of mixed hats) and avoid time-consuming EA activities unless they are “really” justified.

Your comments are most welcomed!

Registration is open for Tech∙Ed Middle East 2011


Tech·Ed Middle East is Microsoft’s premier technical education event providing the most comprehensive technical training on Microsoft’s suite of products, technologies, solutions and services. Attendees get deep technical content, hands-on learning experiences, and opportunities to connect with industry and Microsoft experts one-on-one. If you are a technology professional involved in building, deploying or maintaining IT solutions using Microsoft technologies, Tech·Ed Middle East is the conference that will help you solve today’s real-world challenges and prepare you for tomorrow’s innovations.

WHAT YOU’LL GET AT TECHED MIDDLE EAST 2011

  • Hear about the future of Microsoft’s products and technologies directly from the Microsoft leadership team in the keynote
  • Choose from 200 technical sessions delivered by Microsoft and industry experts
  • Touch the technology through more than 40 PC-based instructor-led training labs
  • Ask your questions at the NEW Ask The Experts forum
  • Meet with product experts and see product demos at the Technical Learning Centre
  • Explore industry solutions at the Tech·Ed Expo

TECHED MIDDLE EAST ATTENDEES RECEIVE A COMPLIMENTARY TECHNET SUBSCRIPTION

As an added benefit to registering for Tech·Ed Middle East 2011, attendees will receive a complimentary Microsoft TechNet Subscription. This subscription gives you access to the most current releases of Enterprise wide software, so you can evaluate and prepare for the needs of your organization before you deploy. See full details of this special offer.

GET A JUMPSTART ON TECHNICAL LEARNING WITH PRE-CONFERENCE SEMINARS

Arrive early and get a jumpstart on your technical learning. Choose from
five pre-conference seminars delivered by Microsoft and industry experts, and selected to give you an edge on the latest technologies and topics.
Seminars will run on Monday, 7 March 2011. Additional fees apply. To view the full list of seminar titles visit us online.

Your Online Resources from Microsoft – MSDN/TechNet


Short Quiz:

  • Do I need to continuously learn and stay a top valued professional?
    • Yes
    • No
  • Will my company pay a lot of money for my learning?
    • Yes
    • No
  • Ok, how can I learn then O_o ?
    • Stick to what I know!
    • Wait forever until someone gives me training!
    • Access free resources of MSDN and TechNet (Webcasts, vLabs, eLearning, blogs, forums, Channel9 and many more)

I guess you know the answers for these questions already, huh?

What does Microsoft provide the Technical Community?

Two main hubs of resources:

With MDSN and TechNet, you can:

  • Get the bits – for free
  • Get trained – for free
  • Get supported – for free
  • Have MSDN+/TechNet+ to get even more!

Ways to get bits for FREE

Get free 60-90 days evaluation copies of various products and tools for free.  You can sometimes get extensions for evals as well.

How to Get Free Training?

Have questions? We Have Answers!

MSDN and TechNet have much more for you..

Thanks to Renat

This content was originally prepared by Renat Minazhdinov from Microsoft.  You can connect with Renat on http://blogs.technet.com/renatmin

If you have feedback, please leave your comments below.

Thanks!

Make Your Mark on the Tech∙Ed Middle East 2011 Agenda


Here’s your chance to tell us which sessions you’re most interested in for TechEd and if there is content missing that you want to see included on the agenda.
Complete our Session Preference Survey and make your mark on the agenda.

For more on TechEd Middle East 2011 visit us here.

Register Now–Free WebCamp on ASP.NET MVC in Riyadh, Saudi Arabia


webcampbadge100What are web camps?

Microsoft’s Web Camps are training events that teach you how to build websites using the latest web technologies including ASP.NET MVC, WebMatrix, OData, jQuery, IE9 & HTML5 and Web Apps.

Where and When?

We’re brining a number of them to Saudi Arabia, and starting off with a web camp on ASP.NET MVC that will be held in Microsoft Innovation Center – AlYamama University, Riyadh – Saudi Arabia on December 27th, 2010.  Both males and females are welcome.

Any material or kits provided?

This is going to be a full-day free workshop (registration required, but no fees) and you’ll get a chance to learn ASP.NET MVC, with presentations, demos, and labs.  Although you can download the web camps training kit for self-learning, we also encourage you to learn from our expert Tariq Ali, and get into discussions and labs that are instructor-led.

The Web Camps Training Kit is completely free :-) and provides all the content that we cover in the events like presentations, demos, demo scripts and labs.  This is the one that will be used throughout the workshop.

What to bring with me?

Be ready to the following before you attend -

  1. Notebook computer <- there will be no PCs provided, and you need to bring your own.
  2. Sketchbook <- in case you want to take notes
  3. Identification <- and ID and registration copy is recommended.

refreshments and snacks will be provided.

How to register?

Please, use the below link to register in the ASP.NET MVC web camp:

Event Name Web Camp on ASP.NET MVC
Date/Time December 27th, 2010. 9:00 am – 4:00 pm
Location

Microsoft Innovation Center
Al-Yamama University
King Fahad Road, North Between Exit 4 and 5
Riyadh, Saudi Arabia

Instructor Tariq Ali – Architect
Language English
Audience Developers
Fees free! registration required.
Registration MSEvents (Event ID 1032472481) 
Calendar Calendar Invite

Looking forward to seeing you there!

Why XAML and Why SketchFlow for Prototyping–in Sketch!


No worries, no reading required.  If you are wondering why Microsoft came up with XAML (the eXtensible Markup Language) with the release of .NET framework 3.0 – which included Windows Presentation Foundation and Silverlight – then this sketch will help you understand that in 14 mins.  This is my try to explain the rational behind XAML and designer/developer concerns using a sketch.  Also, it has a glimpse of why prototyping is important and how SketchFlow (which is part of Expression Blend) addresses this important stage of system and UX design and development.

This is part of a session I delivered in TechEd MiddleEast 2010 which you can watch in full here: Prototyping the UX: Expression Blend + SketchFlow.

شارك مايكروسوفت في فعاليات "أوبن دور ٢٠١٠"


شارك مايكروسوفت في فعاليات "أوبن دور ٢٠١٠" في المملكة العربية السعودية حيث سيفتتح الرئيس التنفيذي لشركة مايكروسوفت ستيف بالمر الحدث ويلقي الكلمة الرئيسية في الرياض بتاريخ ٢ نوفمبر الموافق ٢٥ ذو القعدة ١٤٣١.
شارك في حضور هذا الحدث المشوّق واكتشف كيفية الانتقال إلى الحوسبة السحابية واطّلع على أحدث تطوّرات تقنية المعلومات لدى مايكروسوفت. فعاليات "أوبن دور" هي فرصتك لتطوير مهاراتك التقنية والمهنية ولتعزيز التواصل مع العديد من خبراء تقنية المعلومات.
تفضّل بزيارة www.microsoft.com/saudi/about/opendoor للتسجيل* والحصول على المزيد من المعلومات حول الحدث.
مايكروسوفت المملكة العربية السعودية

الــريــاض
٢ و ٣ نوفمبر ٢٠١٠ الموافق
٢٥ و ٢٦ ذو القعدة ١٤٣١
فندق فور سيزونز

جـــدة
٧ نوفمبر ٢٠١٠ الموافق
١ ذو الحجة ١٤٣١
فندق إنتركونتيننتال

   

clip_image001

clip_image001[1]

   

*يجب التسجيل عبر الإنترنت للتمكّن من حضور الحدث.
إضغط هــنــا للحصول على المزيد من المعلومات عن الــرعــاة لدينا.

Join us at the Microsoft Open Door 2010


Join us at the Microsoft Open Door 2010 event in Saudi Arabia, which will kick off in Riyadh on 2nd November with a keynote address by Microsoft’s CEO, Steve Ballmer.
Attend this exciting event and learn about the transition to Cloud Computing and the latest information on Microsoft’s technology roadmap. Open Door is an opportunity to advance your business and technical skills, and network with many IT professionals.
Visit www.microsoft.com/saudi/about/opendoor to register* and for more information on the event.
Microsoft Saudi Arabia

RIYADH
2nd & 3rd November, 2010
Four Seasons Hotel

JEDDAH
7th November, 2010
Intercontinental Hotel

clip_image001

clip_image001[1]

*Please be advised that online registration is required in order to attend the event.
Know more about our sponsors here.

Blog at WordPress.com.
Theme: Esquire by Matthew Buchanan.

Follow

Get every new post delivered to your Inbox.