Category: Enterprise Architecture


Let’s Talk CTO and Enterprise Architecture

Filed under: Enterprise Architecture, Random Work Day Thoughts — 1 Comment
January 3, 2010

I often find it beneficial when I am trying to learn a new concept to have a real world example so that I might relate the ideas being discussed to my own experiences.  This is why physics as a discipline didn’t excite me much.  It’s often about drawing lines on paper, applying formulas supplied, then drawing other lines to illustrate force + speed + weight to show outcome.   That’s a wonderful area of study for some, but for me I need more concrete examples to relate to.  

With that said lately I have been thinking about the role of a CTO within an organization and how this role relates to the architects who operate within.   In doing so I came up with this imagined example which as it turns out isn’t as much imagined as I had originally thought.

In this business scenario I am going to talk about 3 separate companies all with relatively similar goals.  With each company I am going to illustrate what the CTO of that organization should be thinking about day to day.  I am then going to walk through an example at a high level, and discuss the process  from initial idea through a working implementation.   Keep in mind though this example is very high level.  Actual implementation in some cases takes years to work out.  Also while I am aware of similarities to actual, in no way did any of these companies actually contribute to this post.  All of this is fictional, but could be interpreted to reflect real life situations.

 

COMPANY 1

Background:

When deciding which gadget to buy , I will typically read a few websites which review the gadgets by combining expert reviews as well as user reviews.   Sometimes these reviews are people pimping their products, and other times they are just individuals railing about a particular company and trying to disparage them.   Ultimately after reading both the expert and the general population reviews you can gather some general knowledge of what to look for in regarding the product you’re in the process of buying, or make a decision between similar products. 

The most popular websites make their money through advertisements, whose rates directly relate to the amount of eyeballs that visit their site.  The sites are relatively simple with no actual transactions taking place. 

After some internal research, this company noticed a trend over the last few months that the visitor volume is diminishing. 

If you ask the CTO of this company what he is thinking about day to day what do you think his primary response would be? 

CTO: “How can we utilize technology to improve our visitor count, so that we can maintain or even increase our current income levels?”

COMPANY 2

Background:

There is a website I purchase most of my electronics from.   It’s wildly known to have the best prices on a range of items, and in fact I have personally saved $400 on one HDTV purchase over the local chain electronics store.  

This company makes it’s money on volume.   The more electronics they sell, the more money they make.   Their stated purpose is to drive more and more consumers to their site, while maintaining current customer satisfaction.

While reviewing the site log, the company has also discovered that customers often leave the site to go check on reviews, and in many cases, those same customers never come back

If you ask the CTO of this company what he is thinking about day to day what do you think his primary response would be?

CTO: “How can we use technology to retain customers, and increase usage of our website by consumers intent on buying electronics? ”

 

COMPANY 3

 

Background:

There are many general retailers on the net who sell all kinds of products, but most started as a one trick pony hocking a particular grouping of items, became good at that, then expanded.   A particular website I continue to use to purchase books has stated that it wants to become the one stop shop for everything a consumer would purchase.   Think of the WalMart of the internet with a better user experience and better products.

If you happen to be having a conversation with the CTO of this organization what do you think he will be thinking about?

CTO: “How can we use technology to gain customers and provide that one stop shopping experience for everything a consumer would want?”

Moving Forward

Gaining customers, and retaining customers is the most important aspect of a business.  This is not earth shattering, nor is it ground breaking.  It’s just simple common sense. 

So lets see how each one of these companies go about doing that.

COMPANY 1

The CTO of this company acts as both an outside forward thinking technologist and an inside EA. So placing the EA hat securely on his head, the CTO researches how existing assets can be leveraged as an offering to companies who want to add review functionality to their sites without building the technology themselves.

The CTO/EA interviews the Solution Architect who heads up the website development team and discovers that the website is built on Spring with a Hibernate data persistence layer.  The Solution Architect mentions that it is possible to extend the architecture using SOA principals, and offers to work with his development team to put together a relatively simple demo to illustrate how this can be done.

After reviewing the demo, the Solution Architect is instructed to lead an effort to build a SOA layer on top of the existing website.  Other Solution Architects from the Accounting and Advertising silo’s are employed to build integrations into their existing systems to track sales and consumption of their published services.

The CTO then announces to the corporation’s leadership team that there is now away for consumer sites to use their review technology asset.  

Sales can then introduce this functionality to Company 2 as a service they can add to their site.

COMPANY 2

The CTO speaking with his CEO discovers that they are in negotiations with a rather large online retailer who wants to get into the electronics business without having to actually build the business from the ground floor, or actually buying an online retailer.

Their CTO decides to undertake a program to build a SOA based architecture around their existing infrastructure including their website.   One Enterprise Architect is assigned to write a Governance plan. Another EA is tasked with documenting the current Enterprise Level Architecture with a specific focus on SOA.   While another EA is tasked with developing a detailed plan for building on these existing services and creating new services offerings to meet the business need.  The later two will employ solutions architects who work within the given organizations silos implementing specific business critical solutions. 

Lastly an Enterprise Architect is employed to research the reasons why customer’s leave their site, and come up with a plan to retain them.

After being contacted by Company 1, Company 2 decides to expand their site by consuming the Web Services provided by Company 1.  Part of this agreement, stipulates that the advertisements sold on Company 1’s site must also be displayed when consuming the difference services.

Each and every product sold on Company 2’s website, will have attached to it a set of reviews from Company 1’s site.  This will keep customers from leaving Company 2’s site, and each request to company 1’s site to provide those reviews is registered in their tracking system for future Advertising rate calculations.

 

COMPANY 3

As a well known book retailer that wants to get into the business of selling electronics, the CTO from this company researches the best companies who offer the right set of technologies to allow for the expansion of their site into the electronics world.  To do this, the CTO meets with the CTO of Company 2  to discuss how their technology could be integrated into Company 3’s offerings.  CTO2 explains how they have built a SOA architecture with all of the services needed to both present the catalog, and purchase the items.  But not only that, CTO2 explains that part of their services offering is to provide review services for all of their products, as well as the ability to add reviews to CTO3’s existing catalog.

CTO3 then instructs his EA’s to draw up a plan to add this functionality to their site.

 

SUMMARY

In most organizations the CTO’s responsibility is to use technology to improve business.  They are the forward thinkers within the organization always working to further the agenda of the company by leading technological efforts; to improve organizational efficiency, drive up revenue, foster partner relationships, and in some cases lead efforts to build or improve revenue generating products. In this scenario, we talked about three distinct companies all looking to increase customer traffic and revenue.  In each case the CTO was tasked with finding a way to technologically provide the means to do so.

But a CTO would be useless without an EA.  An EA looks inward, while a CTO looks outward.  Meaning that it’s the EA’s responsibility to lead the efforts across the enterprise to govern and build the systems needed for running the given business.  To put it succinctly the EA bridges the gap between CTO ideas, business problems, and technical implementation.

Tags: , , , ,
Comment

Solutions Architect -vs- Senior Principal Consultant

Filed under: Emotional Intelligence, Enterprise Architecture, Random Work Day Thoughts — Leave a comment
December 19, 2009

There are well known discrepancies in the software industry as to the definition of a Solutions Architect and a Senior Principal Consultant. Depending on what type of organization you speak to, you might get completely different answers to this question.

According to Wikipedia;

A Solutions Architect in Enterprise Architecture is a practitioner in the field of Solution Architecture.[1]

The role title has a wider meaning in relation to solving problems, but is more often used in the narrower domain of Technical architecture – the context for the remainder of this definition. In this context, the Solutions Architect is a very experienced architect with cross-domain, cross-functional and cross-industry expertise. He/she outlines solution architecture descriptions, then monitors and governs their implementation.

The role of “Solutions Architect” requires knowledge and skills that are both broad and deep. To be effective the Solutions Architect must have experience on multiple Hardware and Software Environments and be comfortable with complex heterogeneous systems environments. The Solutions Architect is often a highly seasoned senior technocrat who has led multiple projects through the Software development process or Systems Development Life Cycle (SDLC), and has usually performed in a variety of different roles in that life cycle. The person needs an ability to share and communicate ideas both verbally and in writing to executive staff, business sponsors, and technical resources in clear concise language that is the parlance of each group.”

Strangely Wikipedia does not have a definition for Senior Principal Consultant.   So based on the fact that I have been one for a number of years I have developed my own definition.

A Senior Principal Consultant is a practitioner of Software Solutions Architectures. Providing consulting services to clients, with a broad range of industry experience and knowledge.

This role requires the individual  to be the lead architect, designing implementation architectures as well as defining the development and roll out strategy.   The Senior Principal Consultant must work with multiple layers of an organization, from executes, to business stakeholders, to technical teams and be successful working in all circles.  They must be able to to communicate ideas to all levels and obtain buy in from both the business and technical organizations for their solution architectural designs.

This person must also poses a deep understanding of the business domain as well as the technologies used to solve the different business problems.  A typical Senior Principal Consultant is involved in all phases of a project lifespan from initial requirements gathering, architectural design, task break down, development (where they often act as a software architect and developer), testing, and then eventually roll-out into production.

After reading these two definitions it’s easy to see the confusion in our industry.  Both require depth of knowledge within the business and technical domains.  Both roles require the ability to articulate an architecture to project stakeholders, as well as technical audiences.   Where they differ however, and this is the key, is that the Senior Principal Consultant is more hands on, rather than removed from the implementation.

With that said however, most Solutions Architects I know also love working within the technology space so that they can gain a full understanding of it’s capabilities.  The difference though is that a Solutions Architect is not actually expected to perform the work needed to construct the solution.  They are simply responsible for directing the technical teams, who task it is to build the solution.

My bottom line however, is that the type of person needed for both positions is effectively the same with only minor differences relating to the types of tasks that are performed on a day to day basis.

Tags: , , , , , ,
Comment

Are most Information Technology Architects more Managers or Technologists? Is the 50/50 balance really possible?

Filed under: Consulting, Emotional Intelligence, Enterprise Architecture — Leave a comment
November 15, 2009

IT Architecture is the evolution of a career, in that it takes years of experience designing, building, and rolling out systems that match a set of criteria.   The hardest part as I have detailed in previous posts is not the technology however, but matching the technology to the requirements.   Knowing which questions to ask at the right time, so that you can flush out more from your clients and customers than just a set of screen shots, or a bullet point list of hardware requirements.  The Architect must take a broader outlook then this, always having in the back of their mind what other factors could be impacting the solution, or strategy that have not been communicated.

I recently posted this question on LinkedIn and got a few key responses I wanted to highlight here.

IT architects are visionaries, coaches, team leaders, business-to-technical liaisons, computer scientists, and industry experts. – OpenGroup.com

I believe that a crucial role of a Solution Architect is to act as the link between business stakeholders and technology experts. You need to exchange ideas effectively with both groups and need significant technical and business understanding for this to be possible, without necessariy being an expert in either area yourself. Typically, architects come from a business background and acquire technical knowledge or come from a techincal background and acquire business understanding. In my experience, the latter case is more common and architects are therefore more likely to lean to the technical.  – Paul Harris – CRM and Integration Consultant

In short, the Architect is the only guy in the room who has decent street cred with the Development and Marketing folks. He’s diplomatic and savvy when it matters, and can think very critically about architecture and applying technology where it counts.  AD Kent – Managing Partner at DocuConsulting

As all three quotes explain, the Architect is the link between business and technology, which means that he or she has to be able to communicate and build relationships with both sides.   For instance, if the Architect is in a meeting with the CFO of an organization, project and operational cost are important. It is important to communicate how the given project or strategy will cut costs to the organization.  If you don’t know hard numbers, be prepared to at least communicate in terms of hours spent in the current environment to generate output, and how a new architecture, system, or solution, will cut that down over time.   Many CFO’s can calculate simple math in their head, and when they hear “reduction in hours to produce” they know your talking in terms of savings to the company.    The better your statistics are, the more inclined they are to support your initiative.

This conversation is completely different than the one you would have with engineers and developers.  When communicating with these folks, you must similarly direct your conversation to something that matters to them.  Performance, Design, Quality, Extensibility, Importance to the organization, are all characteristics of an Architectural knowledge base.   It’s also important as the Open Group states, to coach, mentor, and encourage your teams as part of the production endeavor.

So in short, the answer to the overriding question is yes.  The Architect must be someone who can operate with many different hats and gain the respect of peers, those reporting to them, management, and even sales and marketing.   This is often a result of many years of experience in all facets of business technology, and a general understanding of what each component of the business requires to be successful.

Tags:
Comment

Why are customers choosing SOA solutions?

Filed under: Consulting, Enterprise Architecture — Leave a comment
September 9, 2009

Increasing System Integration – Being a standardized method for communication allows multiple systems to interact with one another across the enterprise.

Increased Vendor Neutrality – the ability to use the proper technology at the appropriate time. Vendor neutrality within large organizations is important, in that it allows for the diversity that inherently exists within a corporation without limiting each part of the organization to it’s individual silo’s.

Enterprise Architecture – When you open up your application to other parts of the enterprise as a consumable service – or group of services, it makes the solution available to Enterprise Business Modeling and available as an entity that can be made part of a bigger problem solution. In other words, it gives the Enterprise Architects the ability to use individual solution architectures more as if they were components of a larger model, rather than as a self contained entities.

Reuse – As with the main driving force behind Object Oriented Programming, the ability to reuse logic is a compelling concept. If you build the same component each time you build a new system you in essence have to fund it’s construction each time.

Agility – The ability to use, then reuse – in different ways or for different requirements – system components as the business changes makes SOA extremely flexible to changing business dynamics.

Tags:
Comment

SOA As An IT Asset.

Filed under: Enterprise Architecture — Leave a comment
September 4, 2009

When talking about SOA what we tend to on a technology basis is talk about Web Services.   Services typically encapsulate some unit of business logic, useing a standard method of communication.  Web Services provide a way to develop logic that is originally indicitive of a particular problem, but can be reused by other units within the enterprise.

A real world example of a webservice would be an accounts receivable service.    Calling this webservice with the proper information would cause the accounts receiveable database to be updated with the information that a particular account had been paid.   As a single unit of work this doesn’t sound so terribly exciting.

So let’s use a real world example.   A manufacturing company who manufactures generators has built a new website.   They have streamlined their entire IT infrastructure so that from this single website a client can place an order for a generator and expect turnaround and delivery time within 30 days.

Let’s break down the steps that must occur before the generator is delivered to the client. Assuming the contract was written so that 50% of the money was delivered up front, and 50% after the generated was delivered and installed.

The client would log onto the site, fill out all the specifications that were required, specify delivery location, then add a method of payment.  Easy enough, but how would this web request turn into actual manufactured goods delivered to the site on time

The first step of course is to take receipt the initial payment, and inform accounts receivable that payment has been made.  (Visa.processPayment(cardno) then AccountsReceiveable.makepayment())

The second step is to inform Manufacturing of the desired specifications of the generator and date of expected delivery.(Manufacturing.build(specs,deliveryDate, OrderNo)

Manufacturing would then have to order the parts to build the generator. (DateToBeDelivered = Parts.request(PartsList))

Manufacturing would then inform delivery that the generator is ready to be picked up.  (Delivery.pickitup(ModelNo,CustNo,OrderNo))

Delivery would check the customer database for information on this customer, and this particular order no.  Customer.getInfoOnOrder(OrderNo)

Delivery, once delivered would inform Accounts Receivable that the generator had been delievered, so that the rest of the payment could be collected.  (AccountsReceivable.theyGotIt(ModelNo,CustNo, Date))

Accounts Receivable would then take the last bit of payment.  (Visa.processPayment(cardNo))

While this is simplified in terms of what really goes on when a generater is ordered from a manufacturing company this example illustrates how many different pieces of the enterprise are involved in a given order.  So the obvious question at this point is, why doesn’t the enterprise build one massive system to handle running their entire business.

Because the risk to the enterprise in depending on 1 and only 1 system is to great.   As a nimble flexible and agile enterprise you have to have all of your departments functioning independently of one another.   In our example, you want all departments, Accounts Receivable, Manufacturing,  Delivery, Parts to be working asynchronously of each other, and not dependent.   You also don’t want to have to risk your entire business flow, if you need to do an maintainence release of the software by relying on one system.  So in order to isolate each part of their business company have built silo’s around each individual department so it can operate in a protected mode.

However while protecteing each individual group from a catastrophic failure, companies over time have made it more difficult for these groups to work together.  Each invidual group has it’s own self contained systems to perform it’s given part of the business.   So in our small example, you would have an Accounting system to do Accounts Receivable, you would have Parts System that monitors and keeps track of parts, you would have a system responsible for controlling the manufactureing process.   You would have yet another system responsible for running the delivery process.   Each one of these systems would operate entirely independent of one another.

So how do we join these systems together without making one giant enterprise level application with a single point of failure?   Enter Web Services.  Web Services are the connective tissue of the enterprise.  They open up each part of the business to other parts while maintaining control within each silo.    SOA at the enterprise level is the practice of articulating how the overall enterprise works, in terms of system and dataflow, cataloging the current state, and defining how to solve a global business problem typically using Web Services as the means of communication. A SOA architecture typically tries to align IT with the business in order to fit all the pieces together.  It involves extensive amount of modeling of the current business, so as to articulate the given solution.  This model, then because a basis for communicating how the business is run, from an IT perspective and how each piece fits together.

This is how a SOA enterprise level undertaking become an IT asset.

Tags:
Comment

What are, Design – Standards, Practices, Characteristics, Principles, Patterns, and Paradigms?

Filed under: Enterprise Architecture — Leave a comment
August 30, 2009

System design, while still a very young field and not physical in nature, needs to be more like architecting a physical structure than it is today. In that, it needs to come closer to adhereing to a set of principles and rules that can be generic enough in nature to apply to almost any project, without limiting flexibility and change.   Given the competing natures of the two different endeavors -building a physical structure and building an abstract system – these rules cannot be the same, though there might be overlap.

First let’s get the definitions down.

Design Standards – A set of mandatory rules that the design process must take into account.  Design standards are typically a set of mandates that an organization stipulates that must be applied to any solution architecture.

Best Practices -A set of commonly held and accepted methods or techniques for designing solutions.  As the name suggests, these method and techniques are proven to be successful over many iterations.  This applies to not just the design phase, but design, construction, testing, delivery and support.  These evolve over time, and are pratices that have been found to be consistent and nature and successful in implementation.

Design Characteristics –   Elements or components of a given design.

Design Principles – A collection of fundamental propositions that serve as the basis for a design paradigm.  These are typically industry accepted guidelines for solving specific problems.   Much like Best Practices, principles develop over time, but are instead always applied to the design process.

Design Pattern – Is a typical repeatable solution for a common problem.

Design Paradigm – A set of rules that define the approach to a given design, usually made up by a set of design principles.

Without examples definitions don’t make a lot of sense.

A design standard example would be a requirement from the EA team, that all deployed web based applications must have fail over capabilities.

A best practice example would be; Before any coding gets underway, a formal document must be delivered detailing all of the requirements of the project.

A design characteristic example would be; The system was designed with many reusable  components.

A design principle example would be;  The solution will be distributed.

A design pattern example would be;  An Iterator Pattern, provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation. (Wikipedia)  Another common example of a design pattern is the Model View Controller pattern.  In this pattern the system is broken up into a View layer responsible for showing data and interacting with the user, the Model layer which contains all the business logic and interfaces with the database, and the Controller layer which interfaces between the two and directs view direction.

A Design Paradigm example would be;  Object Oriented Design – which  provides a set of rules governing the practice of solving common problems, encompassing many design principles.

Over the next series of blog entries I am going to explore the world of SOA design principles and concepts, using the definitions provided above and explain how they are used to design a well thought out SOA architectures, given the understanding that each enterprise is different and therefore will have it’s own set of rules governing SOA implementations.

I promise in those entries to use well thought out ideas from over 16 years of designing and implementing solutions, in both a SOA and non-SOA environments, to simply explain how one can go about designing a SOA architeture, while meeting some of the most common business criteria, and ultimately provide the customer exactly what they require.

*To give credit where credit is due, one of the main resouces for this post is http://whatissoa.com.

Comment

Enterprise Architecture Frameworks

Filed under: Enterprise Architecture — 1 Comment
August 24, 2009
An Enterprise Architecture framework provides a collection of best practices,
standards, tools, processes, and templates to assist in the creation of the Enterprise ArchitectureI

I was thinking the other day about large corporations and how they go about defining what the technical direction is for their entire organization. When I originally thought about this, I simply asked myself how do companies choose which technology to build their systems with?  Some organizations choose Microsoft for their server OS, and other organizations use a flavor of Unix.  Some use Java, others use PHP.  How can a CIO really understand why Hibernate makes sense in a certain implementation versus say ADF?    I have implemented systems in many different environments, and have always wondered why organizations, sometimes of the same size, and sometimes with competing business plans would choose such different platforms all together.  In doing some research on this subject I have come across the concept of Enterprise Architecture and Enterprise Frameworks.

What is an Enterprise Architecture Framework?

An Enterprise Architecture framework provides a collection of best practices, standards, tools, processes, and templates to assist in the creation of the Enterprise Architecture

Enterprise Architecture frameworks typically include:

  • Common vocabulary, models, and taxonomy
  • Processes, principles, strategies and tools
  • Reference
  • Reference architectures and models
  • Prescriptive guidance (EA processes, architecture content,
  • implementation road map, governance)
  • Catalog of Enterprise Architecture deliverables and artifacts
  • Enterprise Architecture Content Metamodel
  • Recommended set of products and configurations (optional)

Examples of Framework – Their Definitions According to Wikipedia.

Open Group Architecture Framework (TOGAF) - The architecture is typically modelled at four levels or domains; Business, Application, Data, Technology. A set of foundation architectures are provided to enable the architecture team to envision the current and future state of the architecture.

OMB Federal Enterprise Architecture (FEA) – Enterprise Architecture of the federal Government.   The U.S. Federal Enterprise Architecture (FEA) is an initiative of the US Office of Management and Budgetthat aims to comply with the Clinger-Cohen Act and provide a common methodology for information technology(IT) acquisition in the United States federal government. It is designed to ease sharing of information and resources across federal agencies, reduce costs, and improve citizen services.

The Gartner Methodology (formerly the Meta Framework) - The GEAF describes a business or enterprise context layer that overlays the enterprise architecture to ensure alignment with the business strategy. The business context contains the articulation of the business strategy and its implications. It also articulates external “environmental” trends (such as regulatory requirements, market trends or technology trends) that influence the enterprise architecture. The business context informs the subsequent architecture work.

The DoD Architecture Framework (DoDAF) - The Department of Defense Architecture Framework (DoDAF) provides a foundational framework for developing and representing architecture descriptions that ensure a common denominator for understanding, comparing, and integrating architectures across organizational, Joint, and multinational boundaries. It establishes data element definitions, rules, and relationships and a baseline set of products for consistent development of systems, integrated, or federated architectures. These architecture descriptions may include Families of Systems (FoSs), Systems of Systems (SoSs), and net-centric capabilities for interoperating and interacting in the NCE

The Oracle Enterprise Architecture Framework (OEAF) - The Oracle Enterprise Architecture Framework provides a streamlined technology agnostic framework that helps Oracle collaboratively work with customers to develop strategic roadmaps and architecture solutions that enable business and IT alignment

Decision Making Process

Because the framework documents tend to come from a C-level executive, or from a team of people reporting to a C-level executive, they tend to both take into account the business strategy of the organization and contain the weight of the office.  They are a collection of overall globally researched documents, containing insight into the future direction of the company with an understanding of the current standing of the organization.  As a requirement of the outlined frameworks, these documents are required to take into account organizational growth as outlined by the leadership team, budgetary limitations, and a greater knowledge of current physical and personal resources.

These Frameworks are in essence the technical business plan for the organization.

When undertaking a review about which systems are performing adequately, if data is flowing through the proper channels at the right time, and where the organization needs to improve, these documents provide the main resource for making those decisions.     Each project that is identified as a strategic need for the organization, must meet the criteria laid out in the Architecture Framework documents.  Once a project is identified, choice of vendor, choice of hardware, and in most cases choice of personnel to complete the project must also meet these criteria.

These documents don’t however make the low level choice for the software developers and architects that I was originally thinking about.   Those choices are made by project teams using the Enterprise Architecture document as a guiding set of principals in helping to make the right choices.  So when a team is deciding between an MS platform, or one from IBM they must use these documents as a guiding force in choosing which platforms to go with.


Comment

Hello World!

Filed under: Consulting, Emotional Intelligence, Enterprise Architecture, Programming, Project Management, Random Work Day Thoughts — 1 Comment
June 16, 2009

Hey everyone, this is my first Blog.  I have been a twitter fanatic for about a year now, and a facebook poster for well 2 years.   This is my first attempt to branch beyond that more personal social interaction and setup something a bit more about my professional life.   While there are many blogs out there, detailing all things Java, J2EE, Oracle and the like, there will be, and I promise this, nothing with the unique humor and outlook that I bring to the  table.

We are all unique right..  well I am a unique Geek.  I don’t really fit into your typical stereotype of your total geek, but yet I don’t fit totally into your image of a business guy either.  I straddle these two areas in my day to day life, and it’s my humor and my outlook that keeps me sane.

So as I increase my readership, I hope to learn from, as well as teach those who feel as if the world is an interesting and fascinating place, and that to operate in both the business and technical circles equally and with success, is an enjoyable experience.

Tags:
Comment
Follow

Get every new post delivered to your Inbox.