Thursday, June 18, 2009

Easing Efforts of Servicing Tax Credit Properties

A few years ago, the challenge for the industry was enabling developers to produce an ample supply of communities to meet the demand for tax credit allocations. Syndicators enjoyed the effortless trade of tax credits at rates nearing a dollar -- and occasionally, even more than a dollar. Those days have passed. The uncertain economy continues to reduce the value of tax credits. Concerns over compliance are emerging from institutions that purchased tax credits or dedicated dollars for grants. We have witnessed a radical shift in the industry from driving development production to a focus on compliance with existing properties.

Unfortunately for many, understanding the necessary set-asides for an entire portfolio of properties remains less than obvious. This challenge is compounded when funds are received from multiple sources, since usually those sources each come with their own list of requirements. Projects may receive LIHTC funds, historic tax credit funds, and several grants or loans from various organizations. The result is a unique conglomeration of obligations for each property. Multiplying the compliance demands by dozens or hundreds of properties creates the need for a methodical means to track all obligations.

Owners with a few properties may be able to use a simple spreadsheet to track compliance requirements. However given time, the accumulation a number of units will eventually exceed the capacity for tracking with a simple tool. But, what software is most appropriate for this effort?

By nature, this industry demands flexibility. Starta once tried to develop and deliver “cookie-cutter” solutions, but we quickly discovered that every organization is extremely unique – just as most every project is unique. Granted, there are several fundamentals such as the concept of set-asides and period of compliance. Unfortunately, specifics can radically change, the number of units can differ, the compliance period can vary, and much more. A system needs to provide structured flexibility.

Starta addresses this through an extremely flexible, web-base solution. The system has thousands of data fields available, however, you can select the (for example) thirty-seven fields that are important for your business. You can automatically generate compliance reports every week, month, quarter or year with real-time set-asides, vacancy rates, and rental income received. But, regardless of whether you are a Starta client or not, the important requirement is that your chosen system needs to allow your organization to wrap the solution around the business -- not the business around the technology.

A good compliance system will be flexible enough to handle all of your current compliance needs, as well extensible enough to meet any future needs that arise -- many times, the future needs arrive more quickly than you might expect. Whatever system you choose, just make sure that it is inexpensive to extend if you later find that you need to. This should be a conversation you have with any compliance vendor. The needs of your company are growing and changing with this brave new economy, and you want to make sure that your software systems will be prepared to grow and change with you without breaking the bank.

Starta Development Releases a Compliance Services Tool for Syndicators

Starta Development announced a low-cost solution that enables syndicators to avoid costly penalties that can result from non-compliance with IRS regulations. The service supports a variety of funding, including Low-Income Housing Tax Credit (LIHTC), New Markets Tax Credits (NMTC), HOME Funds, Sections 202 and 811. And, the web-based solution captures not only initial funding documentation, but also incorporates all tenant documents. Further, Starta maintains all information indefinitely.

Syndicators face a significant risk of massive penalties that could result from lost, unfiled, or improper tenant documentation. Starta extends an easy-to-use service to gather and organize necessary compliance details in a central location. Having a web-base solution enables access from anywhere with offsite backups that provide business continuity in the event of a disaster. “There are numerous properties in Louisiana that lost everything. Disaster remains an event that we assume will happen to someone else. With the Starta system, LPs can put aside the worry of losing documentation due to natural disasters," stated Gordon Blackwell, founder of Starta Development.

“The recent focus on major financial institutions has generated a significant amount of concern in the industry regarding compliance of existing portfolio assets,” explains Blackwell. Blackwell further relays that “this is a valuable service that Starta enabled years ago. However with the emerging unease, we have packaged a valuable solution at a very attractive price.”

... Click Here for more details.

Monday, March 9, 2009

Newsletter - March 2009 / The Value of Pipeline Tracking

Pipeline tracking consistently emerges as one of the most valuable activities for housing developers, syndicators and other organizations that manage funds such as loans, grants, LIHTC or NMTC allocations.

Read the entire article at... The Value of Pipeline Tracking

Wednesday, January 28, 2009

The Importance of Software Architecture

Many developers begin developing by unknowingly using the concept of Separation of Concerns (SoC).  They dedicate their time to develop software by designing and developing features (concepts) with as little overlap of functionality as possible. This approach is how I once programmed when I was a developer.  It provides instant gratification.  Unfortunately, this methodology succeeds for only very trivial applications.  The approach is completely inappropriate for large-scale or enterprise-level solutions.

 

The Purpose of Software

The purpose of a software application is driven enviably by the developing organization.  The goals are generally driven with commercial requirements and the ultimate solution must deliver an acceptable ROI.  In most cases, the system’s future return must be promoted to gain buy-in before any investment is allocated.  And in many situations, the architectural design must be leveraged to demonstrate the value and viability of the future system. 

 

The Value of Architecture

I parallel the need for software architecture with the construction of a physical structure –specifically…  I like to relate every system I design as a Tree House, a Home, or a Skyscraper.

 The Tree House Architecture  As a father of 2 children, I enjoyed the assembly of a multi-level, tree house.  I simply fastened boards repeatedly using a level as needed to ensure horizontal floors and vertical walls.  The effort never required pencil, paper, or really much thought.  Similarly, I have developed applications with the same approach –no advance design, just coding.  Unfortunately, the demand for some of these applications exceeded my expectations and brewed into the inevitable catastrophe.

 The Home  While it might be possible to create a home with no plans or design, every family appreciates the architecture of a well designed house.  The general contractor must properly lay a stable foundation while considering all components of the house like plumbing, electrical, rooms and walls.  The GC must also allow some flexibility for the homeowner to acclimate their living conditions within the structure.  For example, while the home’s design must predetermine the location of the kitchen, the homeowner has the opportunity to select the appliances and the exact location of the kitchen table.  When designing the kitchen, the architect must enforce enough structure to enable reliable functionality (the proper operation of the oven and dishwasher) while offering the future owner to determine where they want to place the silverware.

 The Skyscraper  An enormous building relates directly to the enterprise application, demanding considerable design prior to digging the first shovel of dirt.  An architect must respect abstract concepts like the mission and vision; consider al needs, desires, and demands from all relevant stakeholders; encompass all functional requirements; and design to achieve all quality attributes, like scalability, responsiveness, real-time availability, maintainability and/or reliability (often referred to as the ‘-ilities’).  Understanding and achieving the appropriate architecture demands a substantial effort, a focused team, and dedication from all stakeholders.

 

Listening Is Key

The architect must begin by considering a diverse pool of concerns from all stakeholders (users, developers, management, investors, customers, etc).  It is during this initial gathering of information that often forms fundamental flaws in a system.  By neglecting the insights from a key individual, the architect may fail to incorporate a core attribute for the end solution.  Although many circumstances may contribute to design flaws, I believe that the primary issue that surrounds the inability to actively listen to others.  People naturally want to explain their thoughts to support their intentions.  But, this is not the activity for the architect at this phase.  A related problem is the inability for the architect to communicate his or her intentions. –But, we’ll save that issue for a later discussion.

 

What is Software Architecture

At its core, software architecture is a compiled distillation of needs and expectations from all stakeholders.  From its definition, we can recognize that the architecture of a software application will never be flawless.  This is because software always evolves.  While software continues to be used, it is never complete.  Why is software never complete???  Because stakeholders (anyone who is affected by the software) will change their minds, some stakeholders will depart while others will join (Yikes… even after the system is released).  So how do we shoot a moving target?

 

Shooting a Moving Target

There are 3 tools that I use to enable sound system architecture: Pillars, Design Patterns, and Modeling Criteria.  At the most abstract level, an architect should incorporate a set of Pillars throughout the entire system’s design.  A pillar (by my definition) is a central, foundational, abstracted concept that supports the operation and reinforces the mission of the system.  Because each pillar sustains crucial functional support, a pillar can never be removed.  For example, during the discovery of stakeholder’s needs, the system architect may uncover that the solution must allow for a customizable, role-based security model and all actions must be logged and comply with FDA regulations.  The concepts would be 2 pillars of the new system.  Pillars should be documented in concise, understandable terms and leveraged as a litmus test against every designed task.


The concept of a design pattern involves a common reusable resolution to a commonly occurring problem. The concept and use of design patterns has gained popularity and for good reason.  Design patterns speeds development, increases quality, and lessens maintenance efforts by improving readability for programmers who are familiar with the repeated pattern.  Because this concept is well documented, I will not dig into the details relating to the various patterns.

 The final concept that must be incorporated to deliver a robust, scalable and reliable solution involves modeling criteria which must be pre-determined, documented and applied consistently within all designs and code at its lowest level.  Modeling criteria supports the key aspects surrounding quality assurance which facilitates “Fit for Purpose” and “Right First Time.”  Examples of modeling criteria that I often apply include:

Atomic Components (tasks must completely succeed or completely fail)

Loose Coupling (changing one component does not affect the other component)

Open/Closed Principle (components may be opened for extension, but closed for modification)

Dependency Inversion (high-level components should not depend on low-level components)

 

Conclusion

Software will constantly evolve throughout its entire life.  Do not attempt to stop the evolution. Rather record key principles surrounding the project to architect the best solution.  As a final remark, I relate software architecture with the design of an airplane.  The wings of a plane maintain sufficient structure to lift the craft into the air.  At the same time, the wings are designed to flex 22 degrees up and 18 degrees down to prevent a total failure during turbulent conditions, protecting not only the craft, but also all stakeholders. Architects must understand and address all discoverable needs while incorporating a fine balance between structure (for functionality) and flexibility (for customization & user acceptance).  By applying Pillars, Design Patterns, and Modeling Criteria, an architect can achieve a proper design to deliver a scalable, maintainable, and reliable system.

Monday, January 26, 2009

The Power of Strategic Operations

Developing a strategic operation plan is essential to ensure a valued delivery of any product or service.  If you believe that valued quality can occur without purposeful intent, then you may also believe that a dictionary can be created by randomly generating characters.  

An organization must develop a broad set of policies and procedures firm to produce the maximum value from all resources of a firm.  The policies and procedures must also align with the business’ long-term mission.  

Policies extend corporate decisions to staff members that do not possess the authority to make corporate decisions.  With policies integrated in its operations, a company can speed and improve responses for internal and external customers by preemptively extending decisions to lower-level employees.  With a parallel purpose, Procedures document optimal methods that produce a specific result.  While Policies and Procedures differ slightly, both predetermine effective actions to produce the greatest amount of value.

The challenge, especially for young, rapidly-evolving start-ups, is the constant change of internal and environmental factors.  However, change does not excuse the need for structure.  Change actually supports the need for structure.  While policies and procedures are documented, both should continuously adapt to organizational change, customer demands, and learned knowledge.  I refer to this concept as “Agile-Structure”.  Another common term is “Best Practices”.

Regardless of the term, operations must not allow their policies and procedures to become unyielding routines, dictated by inaccessible executives.  Instead this structure should become a technique to produce value more effectively than simply performing in an ad-hoc manner.  Organizations must be adaptive, listening actively to their employees, investors, clients, vendors, and the community.  With well tuned and applied policies and procedures, a company can increase the value and quality of its products and services.


Gordon Blackwell

Technology & Entrepreneurial Evangelist

Raleigh, NC

"Some see things and ask Why...  

I dream and ask Why Not..."

Author Unknown