Architectural Renderings and ERP: A Unique Perspective
What do Architectural renderings, Hawaiian Christmas cards, and ERP have to do with each other? Very little on the surface, yet strangely enough, there is a path…or maybe I’d just rather be hiking. Amongst other things, my father’s long career as an illustrator was focused on architectural renderings. He was a master of his craft and even published a how-to art book on the subject.
As a boy, when I had the opportunity, I used to love watching him perform his work. He possessed a Zen-like focus in bringing architects’ plans to life. Some developers or investors somewhere have a vision of a wonderful development or big dollar signs in their eyes, and they then hire an architectural firm to design, draft and possibly develop their vision.
In architectural rendering projects, my father would start with the architect’s blueprints —large rolls of paper with flat diagrams of buildings all laid out in blue ink. From the blueprints, he would create a perspective as the first step in rendering the building in three dimensions. He would need to first determine the horizon line and the point of view of the observer. This was all very technical and mechanical work. He had these layouts with pushpins, string and rubber bands and was very good at it. Then he would start to connect the dots, pencil in the building in its environment, and from there paint it in complete with sky, landscaping, people and cars in the parking lot. Quite an amazing process. At various points in his career, he would train others to perform the perspectives as they represented more of a mechanical exercise to him, so he could focus on cranking out the finished renderings which required his unique expertise and represented his core competency. The finished rendering would be used in brochures or as part of the sales process to gain funding for building projects and sometimes eventual display as artwork.
One might think that in this day and age you could do this all on computer: Just plug in the specs and render an architect’s design, apply colors, and presto. To be sure, there are programs today that can do all that; however, before there were sophisticated computers and application software, it was largely a manual process. And, as a matter of fact, I had a more tech-savvy friend from my generation who’s an architect once relate to me that with regards to the renderings that he actually switched back to the artistic form because, for some reason, the computerized renderings were almost too realistic and lacked the quality of fantasy required to sell projects. This serves as a reminder to never lose sight of why you are automating a task and the ultimate purpose, objectives, or vision in your particular project.
When building development began to slow down in L.A. in the mid-70s, my father decided to move to Hawaii where building development, especially for resorts, was booming. He even had family friends there working on Hawaii 5-0: Book ’em, Danno! As an illustrator, he began to ply his other fine and commercial arts skills and started creating Hawaiian Christmas and greeting cards, kind of a reinvention of an earlier business he had on the mainland. He was the first to create designs like Santa surfing in Hawaiian attire with reindeer or flying a small sled over the islands, all kinds of Hawaiian scenes — some cartoony and humorous, some elegant in foils like a dolphin leaping, flowers or a rainbow. Initially, he was designing and illustrating the originals, then printing the cards, and then running around trying to distribute them all himself. Ultimately, he decided to engage distributors to handle the printing and distribution work so he could focus on what he was best at, which were the creative aspects of his work. He taught me that it was better to make a smaller percent on a much larger volume of sales than to make all the profit on a very small quantity of sales. He also learned from his distributors that “Green doesn’t sell,” or that the cards that contained a majority of green in their image didn’t appear to perform as well as some of the other better selling designs—something to keep in mind if you ever find yourself in the business of Hawaiian greeting cards.
The other thing my father taught me is that you never have time to do it right in the first place, but always have time to do it again if you didn’t. I think he was referring to his renderings and how an architect might have a job and there was always a “rush” and he was under the gun to deliver on deadline and then the client would change something and he’d have to re-do or rework an entire manual project.
Architectural renderings, card design, and ERP projects all contain very similar elements in that you start with a client, end consumer, or user who has some kind of vision, objectives, needs or requirements which you are trying to meet or fulfill in order to deliver something of value that they are willing to pay for. An architectural rendering, and any illustration for that matter, starts with a perspective, meaning you have to understand the viewpoint of the potential observer, how something might look from where they stand in relation to the entire environment and connect all the dots into a comprehensive picture or solution that matches the vision.
In software implementation you should first understand the viewpoint of the business and what it is trying to accomplish. Next, there are the users (remember, Tron, you’re supposed to fight for the users). How do they perform their work today? What are they trying to do? How can we utilize automation to help them become more efficient and productive? One clue: It’s not what you or the IT Director dictates, it’s what the user says it is and their viewpoint that really counts. At the end of the day, if you do not implement a system and fight for the users, they will rebel and not embrace it as a useful tool, and you can watch your $100K – $1M investment in automation and technology bite the dust.
Lastly, there is the actual solution, which is no longer a single system, but a vast and complex matrix of components which can consist of business processes, how users access and use the system, various software solutions, hardware, large electric bills, and so on. How does the system need to behave? What are its functional requirements (what does it need to be able to do)? What are its non-functional requirements, i.e., how does it need to behave, and what qualities or characteristics must it possess?
If you want a highly functional solution, users that embrace it, and to realize business value from it, you must be willing to ask these apparently obvious yet sometimes difficult questions, organize or synthesize the answers and then implement the solution. It is the viewpoint of the observer that unites seemingly disparate points, has a vision, as one would with architectural renderings, Hawaiian Christmas cards and ERP software implementations, into a unified picture with goals, objectives, a mission and a plan. There are users that will utilize it to perform their work, software components, infrastructure and an implementation team or partner up to the challenge. These represent tasks that people—you and I—are required to perform, not computers, as part of the implementation process.
And remember: Green doesn’t sell.