Cool Solutions

Designing a Rock-Solid ZENworks Infrastructure

coolguys

By:

March 9, 2006 7:31 pm

Reads: 2923

Comments:4

Score:0

There are five (5) phases to ANY ZENworks design and implementation, regardless of size and complexity. These are:

1. Business assessment (requirements gathering activity)
2. Technical assessment (requirements gathering activity)
3. Design your architecture (design phase activity)
4. Development, testing, and pilot deployment (design phase activity)
5. Wide-scale deployment (deployment activity)

Business Assessment

During this phase you are going to meet with key stakeholders within your organization and assess what is required from a ‘business’ perspective. What end-user, and management needs do you need to address to ensure that you are designing the right architecture, and deploying the right services. Believe it or not this can kill a project, make you look like a rockstar or a failure. This also affects your end-state solution architecture, so do not discount this activity.

Technical Assessment

During this phase you are going to ensure that all the necessary infrastructure components are in place, healthy, and ready for the ZENworks deployment. Your infrastructure needs to support ZENworks so spend time to ensure everything is up to snuff.

By the end of your business and technical assessment you should have everything documented (I know you love doing this), and you should have a high-level design thought out and approved.

Design your Architecture

This phase is the big one. This is where you are going to go into extreme detail and design your end-state solution (more on this later – see “Mark’s Rule of Thumb on Design” at the end of this post). You are going to get granular here and place a lot of rigor around ensuring you are not making any mistakes. You will be meeting with teams of individuals to flesh design elements for all the individual pieces of the ZENworks suite that you will be implementing. You will document everything, and your deliverables are a detailed design report and a detailed set of architectural diagrams. I know this sounds like a lot, but you want to ensure that you are deploying the services only once and you want to avoid making mistakes.

Development, Testing, and Pilot Deployment

This is where you are going to test the crap out of everything you’ve designed in the previous phase, in your mock lab environment (remember, your lab needs to reflect the end state design – on a smaller scale of course), and tweak your design if necessary. Any time you make changes to your design you are going to update your design materials (the deliverables from the previous phase). Then… when you finally think you’ve got everything right and you’ve spent a bunch of hours doing your due diligence you are going to pick a group of individuals in your company (people that you probably don’t like much) and call them your ‘pilot group’. Your going to test stuff out on these people, and they are going to give you feedback.

Wide-Scale Deployment

The last phase is your production, wide-scale deployment. This is where you are going to deploy the remainder of the backend services and desktop agents to support your entire company (over and above the stuff you deployed to support your pilot initiative). This should be point and click, and there is should be little to think about. Remember, you’ve done everything up front… so now it’s just a cake-walk.

Mark’s Rule of Thumb on Design

You should spend roughly 80% of your time on assessments, design, testing, and piloting, and the remainder of the time should be spent on deployment. Regardless of the size or complexity of your implementation. If you follow these general guidelines (of course with a good understanding of the ZENworks product suite) your architecture should be rock-solid, and your implementation successful.

Feedback is always welcome.

Peace.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Categories: Uncategorized

Disclaimer: This content is not supported by Novell. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.

4 Comments

  1. By:Alex

    How about a start-to-finish example? This was a good start, but a whole writeup about an actual implementation would be exremely helpful.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
  2. By:Mark Schouls

    You got yourself a deal! I meant this to be a summary, and was hoping to drill down into more detail in future posts. There is simply too much to do in a single post. I will tackle this in phases, and post in part each week.

    In addition, if you are planning to attend BrainShare 2006 in SLC I suggest you attend my session on ZENworks Desktop Management Best Practices (TUT245) for more detail.

    Cheers dude.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
  3. By:Laurence

    Great post Mark, however some additional stages:

    1a. Document
    2a. Document, review.
    3a. Document, test, update document
    4a. Update documentation

    Not that the documentation is important ;o)

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
  4. By:Mark Schouls

    Your stressing a very important point Laurence – documentation. The design document (and other supplimental materials that you will have written) is a living breaching document and should accurately reflect not only your design/architecture, but all of the many many decisions you and others made.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)

Comment

RSS