man me pt. 4

I was originally hired by Toll Brothers to maintain and update an internal legacy application for the Land Development department. But after a couple weeks I found that task would realistically only take a fraction of my potential bandwidth. So I turned my attention to the state of the company's application infrastructure. I saw a young IT department still finding it's legs in a mature company. I saw many different departments having different applications, some .Net apps, some Java apps, a Perl app, some apps using Oracle, some SQL Server and one using MySQL. No shared class libraries and minimal if any code re-use. This heterogeneous environment was a result of different departments within the company acting independently of IT, hiring outside contractors and even in-house developers working exclusively for their department, to build their applications for their immediate needs, not concerned with adhering to or establishing standards.

Seeing this, I began a series of weekly meetings with the leads of the different applications to try and find points of commonality. With the sheer volume and scope of applications it would be unrealistic to re-write the applications under one technology - instead I proposed that we move the business logic that the apps had in common to a central repository: a series of web services that would use abstract base classes and interfaces to allow departments to inherit and implement their own specialized classes while data that any other application on the enterprise could access and have a hook into. After all, Toll's main business model was project based - projects being tracts of land and each department had their own view on the tract of land. Land Purchasing focused on buying the land, Land Development focused on what to do with the land (twenty estates homes or seventy townhomes?), Sales focused on selling the homes built on the land. Land was even kept as an asset for potential liquidity. So projects were the biggest point of commonality, even if departments had access to different views of a project, at least they would still be talking about the same project and any changes to that project would be reflected real-time in every other app in the enterprise.

Having the business logic be available via web services then opened up the possibility of expanding the services that were offered to clients (from a Toll IT perspective clients were other internal departments). Specifically creating mobile applications, or mobile extensions to existing applications, that would consume the web services and feed data back to the enterprise for real time exception reporting.

Once we had decided on a company-wide standard for mobile phones, ie what specific phone, OS and carrier we would use, I started to create the base skeletal functionality. More r&d and proof of concept than actual business implementation, I fleshed out routines for authenticating the web services with the Novell servers and the core store and forward patterns that all new apps would use for offline use.

When the first mobile project was then approved I served as the technical lead for an off-shore team of developers who fleshed out the business logic on top of the skeletal structure I provided.

Toll was both a really good and very interesting experience for me.  It was the first large company I worked for, the first publicly traded company.  My first exposure to SOX compliance, the first time I was in-house in such a heterogenous environment.   Had the housing market not taken a dump when it did, making staying at Toll a volatile prospect, I would probably still be there to this day.  

I made a lot of friends while I was at Toll, some of which have become very good friends that I still see to this day.  One of which then brought me on to my next company with him.