Thursday, June 18, 2009
Easing Efforts of Servicing Tax Credit 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
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
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.
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.
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