Considering this is the first “Consulting Wisdom” post of the Wisdom Series, I would like to explain my goal for this category. I’ve been in Consulting for almost six years now, all in the technical field. I don’t consider myself a guru, but over the years I’ve experienced a few things that I can share for everyone to learn from. That is the goal of this series, and I hope in some sort of fashion this may be of use to your career.

At some point in a project (hopefully), you’ll get to what we usually call the “Go-Live” day (i.e. the launch date,  the drop-dead day, the D-day, etc) and with that said, I say: CONGRATS!!!

Not a lot of projects reach this point of the game. If your team is one of the few ones, consider yourself lucky. It takes a combination of a good team, a reasonable client and a realistic project for this to happen. However, this eventful day where you turn the switch “ON” doesn’t usually go as easy as it sounds.

Have you heard of Murphy’s Law? Paraphrase in multiple ways, essentially it goes like this: “Anything that can go wrong, will go wrong”. For multiple projects I’ve worked with, Go-Live day and Murphy’s Law usually goes hand-in-hand. It may not be everything going wrong but somewhere along the line there will be some sort of surprise that is unaccounted for. Regardless if you’re not the Tech Lead, Architect or some other leadership role there is one mantra that you should tell yourself:

We are going live today, We are going live today, We are going live today.

Go-Live dates are usually the most stressful time of the project. All the hard work, sleepless nights, endless meetings are now finally coming to fruition. It is your duty as a consultant to have this mantra and attitude that would affect not just your psyche, but also the client. Everyone will be antsy, especially the client, heck why wouldn’t they? They’ve paid us thousands of dollars to help them with their implementation. Some may even have their jobs on the line! If there’s a time to take some stress pills this would be the perfect time to do it. Honestly though, what truly would help you and your team is to have the right attitude when you reached this pivotal stage.

Arm with the right attitude everything becomes just a matter of execution. If something goes wrong, you would need to think on your feet and react smart and judiciously. It is without question a test of your wits in how to solve a problem the most efficient way as possible. Whether asking for some assistance from a team member, calling some assistance from a colleague, you must be ready to give your absolute best in getting over the hump.

One of the few things that most team at this stage worries about is whether or not everything is perfect. More than likely it won’t be. Heck, it’ll never be. Your goal and only goal for this day is not making sure its perfect, but rather getting the project live as scheduled. It is ok to have a patch or two after the release. What you need to worry about is what the client considers as the “show stoppers”.  If your team can resolve any of the show stoppers (the earlier the better) before going live, then any other issues can potentially be fixed later. The client must be the one that nails down the bare minimum product, so hopefully a couple of weeks before the go-live date your team have identified the show stoppers and have resolve everything on or before the go-live date week. If you think there’s a feature or bug that is unaccounted make sure to bring it up now to the whole team, including the client, or it’ll creep up during the go-live week. The less surprises you have the better, so that when the go-live date arrives, surprises that comes with double the anxiety level  won’t be as much.

One of the few ways I’ve done prior to the go-live date is having everything in place the day before (ala Practice Go-Live day). Hence, there’s little planned work to be done on the actual go-live date. Also, it gives the team enough buffer time and confidence whether things will go smoothly. For example: Finish all the production migration/configuration the day before, wherein all you have to do on the go-live date is configuring the public domain hostname that points to the production server. More importantly by doing it one day ahead it gives you a proper assessment whether the team is still on target or whether it would have to be a pushed for a few more days. Remember that in any project you must always set the right expectation to the client so they won’t be surprise when they missed the scheduled date. Missing the scheduled date to go live by knowing it the day before, is usually better than not getting it live on the day that client have expected it. Again, limit the surprises as much as you can.

Considering all of these… Sleep well the night before. Clear out your calendar. Make sure that you’re in the best shape when you wake up.

It’ll be a long but wonderful day for…

We are going live today, We are going live today, We are going live today.

So in the spirit of sharing, I’m starting a new series called: “Wisdom Series“. I’m calling it “Wisdom” more so because much of the post that I’ll be sharing are all real-project experience that I’ve personally encountered throughout my clients instead of just random “knowledge info” that you can readily obtain by searching the docs.day.com or some other websites. Also, I like “Widsom” in general, since it was my class section name back in Grade 5! Ah… those were the days…

For starters, I’ll divide it up into two different categories:

• Tech Wisdom – talks about different AEM specific or other technical info, tricks, etc.
• Consulting Wisdom – talks about different consulting engagement do’s/don’ts, etc.

Anyway, hope I can continue this series going for as long as I can and hope you guys see some use from it.

For the first Tech Wisdom series I’m sharing, it’ll be in regards to the newly introduced concept of “Project” in AEM 5.6. It’s a good concept however there is still much to be desired as far as the current implementation.

Tech Wisdom #1: AEM 5.6 – Project Creator

OVERVIEW

One of the new changes in AEM 5.6 is the Touch UI.  Upon login, the first section that the user will see is the “Projects” section as shown below:

However for some odd reason, there is no UI available at all to create a new Project.

And so, the Project Creator I’ve created exposes this “Projects” area in Tools menu and adds a new console called: “Project Creator” as shown below:

USAGE

To use the Project Creator simply do as follows:

• Install the “PVN-ProjectCreator-1.zip” package. (Download here)
• Once installed, simply go to the “Tools Console > Projects” then double click “Project Creator”. You should see the following console below.

• Fill in the proper fields as shown above then click “Create Project”
• That’s it! You should see a project created similar to the one below:

NOTES

• All the code resides under /apps/projectCreator
• A sample project has been added called “Project Title” as shown above.
• This is the first release, if you have any questions/comments please send me an email at: pnolasco@adobe.com. If time allows, I’ll try to reply as much as I can.

ENJOY!

“Your mission should you chose to accept is to build a CQ site in four weeks and all you have is a series of design comps”

Sounds fun eh? Well it actually happens in most projects that I’ve been in. You see in most cases clients decide to build a new site in the following order:

1. Client buys CQ/WEM.

2. Client hires design firm to design the new site.

3. Client hire us to implement the site based on the design comps.

So where/how do you start? (That’s usually the question that clients ask us on the first day of the engagement).

Before I go technical here, there’s ALWAYS one thing that should come first regardless of the project: Business first.

So understand what the project is all about, why CQ/WEM was purchased and what is its driving purpose. Project success are measured not by the elegance of the design nor the complexity of the code, but rather meeting (and exceeding!) the expectations.

Once that is clear then it’s a matter of following few simple rules in the “comps-to-components” translation. (Note, it would be easier to follow the instructions below with samples. Unfortunately most samples that I have are client sensitive data, and it’s hard to find samples online).

1. Identify the templates – Design comps always have some sort of pattern. Even though most designs are quite open-ended and not CMS-optimized (i.e. Most design firms don’t under the concept of re-usability, hence pages are usually designed as pretty as possible without any further thought how it would be translated to code), there is a pattern. Page design usually have a footer and a header and a variation of content in the middle. Whether there’s a left, right or top navigation, there is a pattern.

In most cases, there will always be a “Home Page Template” and a “Default Page Template” (i.e. templates that is used to design internal pages). A Default Page Template can usually be broken down to multiple other templates. It all depend whether you want to create: content templates (templates are used to make it easier/faster for authors to create content without adding any other component), generic templates (templates are open-ended and can add components), or a mix of both. The key here is you want it to be simple and it make sense for authors to use it.

2. Identify the components – This is the most difficult thing in deciding what is a component and what is not based on the comps. It’s easy to take a look and see the structure of the design. There’s a footer there, a header here, a navigation on the side, and so on and so forth. However, the key here is figuring and answering a few things: How will the user insert/edit the content? How will the content be stored? Where does it come from? What is its behavior? As you notice, the theme here is: content. Content is king in the world of CMS. Identifying components should always answer these questions.

However, despite all of these… keep the design simple. Do not complicate the component and make it do too many things at once. You should always think of it as a simple method that does one thing and one thing only. In some cases, you have to make it complex but try to keep it at a minimum.

That’s basically it! Pretty straightforward and simple right? Heh… But as always, practice makes perfect. Enjoy cq-fying those designs!

Additional Notes:

• Keep in mind that most site designer have no clue how CMS works in general. So if you had to pick, a good component/template design is better than following the design comp.
• Design comps are just guidelines. At the end of the day  a CQ designer/architect has the final say on how it should look and what make sense in terms of maintaining the code and making it flexible for future changes.
• Make sure to study the OOTB components/templates that comes with CQ. They’re the best guidelines out there. It’s ships with the product for a reason.
• Finally… If all else fails you can always blame the designer.

What in the world am I talking about?

For the “culturally-challenge” individuals when someone is referred to as “Kool-Aid drinker”  it means someone who blindly believes in a certain ideology without questioning common sense. For the “acronym-challenge” individuals ADEP stands for “Adobe Digital Enterprise Platform” and WEM stands for “Web Experience Management” (Take note that WEM is one of the solution that is provided by the ADEP platform, it used to be referred as Communique but the marketing team doesn’t like the spelling or something).

Pragmatist is someone who make sense, a realist, or pretty much someone who for all purposes believes that in practice lies the true meaning. I’m a pragmatist by heart, and so far it did me well.

So why do I consider those that admire the ADEP WEM platform as pragmatist? Well there are multiple things but to get started I’ll first explain it by listing out the things that I admire about WEM.

1. One-click wonder – In my previous  consulting engagements where I’m working with other CMS systems, installations can take as long as a week. That’s just installation of the core product. If you want to install the rest of its part then you would have a day or two more. In ADEP WEM, a click or one-execution of command will do the trick. This saves a consultant the hassle of getting everything right and saves the client some consulting budget that could be re-allocate in what actually counts (i.e. building the site).
2.  It’s all about the package - Compare to other CMS systems almost everything a typical enterprise site would need comes with the core WEM solution. Digital Asset Management is part of the product. A web-based IDE is included or a desktop-based IDE can be downloaded for free. A source-code control system FileVault is included as well. It has it’s own app server with CQSE. It includes basic analytics gathering. Deployment from the “authoring side” to the “publishing side” is part of the product, no need for a separate installation for a FTP like deployment tool.  No database is needed — this saves time and quite a headache since getting any database schema defined by the DB Team of the client usually would need to jump to a series of approvals.  It even comes with an “App Store/Android Market” like capability with Package Share. Oh and that “mobile-revolution” we’re experiencing right now well, it’s there too emulated for your viewing pleasure. In all, with installation alone, it probably saves the client at least two weeks of engagement or if you equate that to the usual consulting rate it results to about $10,000 – 20,000 of savings! (Who doesn’t like saving money?).
3.  We’re open 24/7 – The core technology is open to the public. JCR, Sling, and OSGI are all open source and can be easily extended using libraries that are available outside the hallowed and secured halls of Adobe.  This results to easy integration with custom systems and environment (which, almost 99.9% sure any engagement would have some sort of custom integration with their system).

In summary… What kind of person wants to build something but want it to be: easy to build, comes with almost everything you need, and “Oh, just in case you’re missing something you can add it in with no restriction”? Yeah… that’s right a pragmatist.

A quick introduction. I’ve been working with enterprise content management system from Vignette’s VRD system, Interwoven’s TeamSite, and other open source such as Joomla and Mambo. I’ve started website development around 1999 when I launched my own community of music video editors at: www.nkode.net. Ever since then I’ve enjoyed working in this field and I was lucky enough that my career path lead me to one of the top web innovators of today with Adobe Systems.

I’ve been a technical consultant with two other well-respected software company: HP-Autonomy and OpenText-Vignette and one thing that I learn is that there’s no such thing as a perfect content management system. However, (regardless on how bias this might sound) Adobe’s WEM (formerly known as Communique) is perhaps one of the neatest product that I’ve worked on in building websites. What sets it apart from other product is how robust and well-conceived it is. Heck to start, tell me another CMS that has it’s own web-based IDE? But seriously though, the reason why I think ADEP WEM’s platform is unique than all other CMS I’ve worked before is its repository — CRX. The flexibility of having everything in one location creates a very unique system.

Well, enough of this technical stuff…  I hope you guys/gals enjoy reading my blog. I’ll try to keep it easy to read, more hands-on examples and pictures (in short… NOT BORING… that’s tough for any tech topic). I’ll be posting topics mostly as it relates to Adobe’s Digital Enterprise platform, however I’ll squeeze in some tech topics unrelated to Adobe but related to some CMS or the overall tech industry.

Redundant as it may be… But again I warmly welcome you to my blog!